Netty's epoll transport fails to detect and close TCP connections that receive a RST after being half-closed, leading to stale channels that are never cleaned up and, in some code paths, a 100% CPU busy-loop in the event loop thread.
All versions of 4.2.x netty-transport-native-epoll up to and including 4.2.12.Final
4.2.13.Final (fix merged into the 4.2 branch via #16689; release not yet cut as of 2026-04-25).
Medium — Denial of Service (resource exhaustion / CPU spin)
CWE: CWE-772: Missing Release of Resource after Effective Lifetime
When a TCP connection using Netty's epoll transport has ALLOW_HALF_CLOSURE enabled (or is in a half-closed state via the HTTP codec), and the remote peer:
SO_LINGER=0)the server-side channel is never closed. This happens because:
epollOutReady() is a no-op when there is no pending flush.epollInReady() short-circuits via shouldBreakEpollInReady() because input is already marked as shutdown.EPOLLERR/EPOLLHUP error condition is therefore never processed, and channelInactive is never fired.Depending on the Netty version and configuration, this results in:
clearEpollIn0() is not called during the ChannelInputShutdownReadComplete event, epoll_wait returns immediately on every iteration for the affected fd, causing 100% CPU utilization on the event loop thread and starving all other connections multiplexed on it.4.2 branch at commit 0ec3d97).{
"cwe_ids": [
"CWE-772"
],
"github_reviewed_at": "2026-05-06T23:10:41Z",
"github_reviewed": true,
"severity": "HIGH",
"nvd_published_at": null
}