Skip to content

← Public intelligence

Maven package

io.netty:netty-transport-native-epoll

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 4.0MavenPublished

    Netty: Unix-socket fd receive leaks descriptors when peer sends two at once

    CVE-2026-45536 · GHSA-w573-9ffj-6ff9

    Affected
    • Maven io.netty:netty-transport-native-epoll >= 4.2.0.Final, <= 4.2.14.Final; <= 4.1.134.Final
    Fixed in
    4.2.15.Final4.1.135.Final· Vendor fix available
    Issue
    nettyunixsocketrecvFd sets msgcontrol to char control[CMSGSPACE(sizeof(int))] (line 940) — 24 bytes on 64-bit Linux. A peer-sent SCMRIGHTS cmsg carrying two ints has cmsglen = CMSGLEN(8) = 24, which fits exactly with no MSGCTRUNC, so the kernel installs both fds in the receiving process. The subsequent check cmsg-cmsglen == CMSGLEN(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 MSGCTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILEDESCRIPTORS (non-default).

    Recommended action: Upgrade to 4.2.15.Final or 4.1.135.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →