Summary
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.
Affected versions
All versions of 4.2.x netty-transport-native-epoll up to and including 4.2.12.Final
Fixed in
4.2.13.Final (fix merged into the 4.2 branch via #16689; release not yet cut as of 2026-04-25).
Severity
Medium — Denial of Service (resource exhaustion / CPU spin)
CWE: CWE-772: Missing Release of Resource after Effective Lifetime
Description
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:
- Sends a FIN (half-close), causing the server to mark the input as shutdown, then
- Sends a RST (e.g. by closing with
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.- The
EPOLLERR/EPOLLHUP error condition is therefore never processed, and channelInactive is never fired.
Depending on the Netty version and configuration, this results in:
- Stale channels: The connection is never closed or deregistered. An unauthenticated remote attacker can repeat the sequence to accumulate stale connections, exhausting file descriptors, memory, or connection-count limits.
- CPU busy-loop: In code paths where
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.
Mitigation
- Upgrade to 4.2.13.Final when released (or build from the
4.2 branch at commit 0ec3d97).
- If upgrading is not immediately possible, configure idle timeouts on connections to limit the lifetime of stale channels.
Resources
References
Stormpx Finder
Summary
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.
Affected versions
All versions of 4.2.x
netty-transport-native-epollup to and including 4.2.12.FinalFixed in
4.2.13.Final (fix merged into the
4.2branch via #16689; release not yet cut as of 2026-04-25).Severity
Medium — Denial of Service (resource exhaustion / CPU spin)
CWE: CWE-772: Missing Release of Resource after Effective Lifetime
Description
When a TCP connection using Netty's epoll transport has
ALLOW_HALF_CLOSUREenabled (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 viashouldBreakEpollInReady()because input is already marked as shutdown.EPOLLERR/EPOLLHUPerror condition is therefore never processed, andchannelInactiveis never fired.Depending on the Netty version and configuration, this results in:
clearEpollIn0()is not called during theChannelInputShutdownReadCompleteevent,epoll_waitreturns 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.Mitigation
4.2branch at commit0ec3d97).Resources
References