GHSA-rwm7-x88c-3g2p

Suggest an improvement
Source
https://github.com/advisories/GHSA-rwm7-x88c-3g2p
Import Source
https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/05/GHSA-rwm7-x88c-3g2p/GHSA-rwm7-x88c-3g2p.json
JSON Data
https://api.osv.dev/v1/vulns/GHSA-rwm7-x88c-3g2p
Aliases
  • CVE-2026-42577
Downstream
Related
Published
2026-05-06T23:10:41Z
Modified
2026-05-14T18:16:24.724145Z
Severity
  • 7.5 (High) CVSS_V3 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
Netty epoll transport denial of service via RST on half-closed TCP connection
Details

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)

CVSS: 3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 7.5

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:

  1. Sends a FIN (half-close), causing the server to mark the input as shutdown, then
  2. 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.

References

  • Issue: https://github.com/netty/netty/issues/16683
  • Fix: https://github.com/netty/netty/pull/16689
Database specific 
{
    "cwe_ids": [
        "CWE-772"
    ],
    "nvd_published_at": "2026-05-13T19:17:23Z",
    "severity": "HIGH",
    "github_reviewed_at": "2026-05-06T23:10:41Z",
    "github_reviewed": true
}
References

Affected packages

Maven / io.netty:netty-transport-native-epoll

Package

Name
io.netty:netty-transport-native-epoll
View open source insights on deps.dev
Purl
pkg:maven/io.netty/netty-transport-native-epoll

Affected ranges

Type
ECOSYSTEM
Events
Introduced
4.2.0.Final
Fixed
4.2.13.Final

Affected versions

4.*
4.2.0.Final
4.2.1.Final
4.2.2.Final
4.2.3.Final
4.2.4.Final
4.2.5.Final
4.2.6.Final
4.2.7.Final
4.2.8.Final
4.2.9.Final
4.2.10.Final
4.2.11.Final
4.2.12.Final

Database specific

source 
"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/05/GHSA-rwm7-x88c-3g2p/GHSA-rwm7-x88c-3g2p.json"