Netty Unix Socket CVE-2026-45536

The vulnerability resides in the native C function netty_unix_socket_recvFd within Netty's JNI transport modules: io.netty:netty-transport-native-epoll (Linux/epoll) and io.netty:netty-transport-native-kqueue (BSD/macOS). At line 940, the control buffer is allocated as CMSG_SPACE(sizeof(int)) = 24 bytes - sized for exactly one file descriptor. When a peer sends an SCM_RIGHTS ancillary message containing two integers (two FDs), the resulting cmsg_len is CMSG_LEN(8) = 24 bytes, which fits exactly in the 24-byte buffer. Because the buffer is not overflowed, the kernel does not set MSG_CTRUNC, and both peer-supplied FDs are silently installed into the receiving process's file descriptor table. The validation at line 972 checks cmsg->cmsg_len == CMSG_LEN(sizeof(int)) (expected value: 20), which fails for the two-FD message (actual: 24), so the fd-reading branch is skipped. Critically, neither installed FD is closed. The for(;;) loop then calls recvmsg again on the non-blocking socket, receives EAGAIN, which the Java layer maps to 0 and treats as normal loop exit - leaving two untracked, unclosed file descriptors per message. There is no MSG_CTRUNC handling in the code path. While NVD assigns CWE-200 (Information Exposure), the primary mechanism is more precisely CWE-775 (Missing Release of File Descriptor or Handle after Effective Lifetime); the CWE-200 classification may reflect that the peer's file descriptors are installed into the process without authorization.