Vulnerability
Netty: Unix-socket fd receive leaks descriptors when peer sends two at once
netty_unix_socket_recvFd sets msg_control to `char control[CMSG_SPACE(sizeof(int))]` (line 940) — 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check `cmsg->cmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking → EAGAIN → Java maps to 0 → read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default).
No CVSS base score from NVD or GHSA yet. NVD typically scores within 24–72 hours of publication; GHSA usually within a day for OSS-flagged CVEs. Last record update .
For interim severity, fall back on KEV / EXPLOIT signals and the EPSS percentile (lower panel). Re-check this CVE after one cron tick — the score lands automatically when the source publishes.
Low exploitation likelihood — defer if no other signals fire.
No VEX statements published for CVE-2026-45536. Vendors publish VEX (Vulnerability Exploitability eXchange) to assert per-product whether a CVE is actually exploitable in their distribution.
No exploitation, limited impact or prevalence