GHSA-RWM7-X88C-3G2P

Vulnerability from github – Published: 2026-05-06 23:10 – Updated: 2026-07-24 19:05
VLAI
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-classes-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
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-transport-classes-epoll"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42577"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-772"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T23:10:41Z",
    "nvd_published_at": "2026-05-13T19:17:23Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nNetty\u0027s 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.\n\n## Affected versions\n\nAll versions of 4.2.x `netty-transport-classes-epoll` up to and including 4.2.12.Final\n\n## Fixed in\n\n4.2.13.Final (fix merged into the `4.2` branch via [#16689](https://github.com/netty/netty/pull/16689); release not yet cut as of 2026-04-25).\n\n## Severity\n\n**Medium** \u2014 Denial of Service (resource exhaustion / CPU spin)\n\n**CVSS:** 3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - **7.5**\n\n**CWE:** CWE-772: Missing Release of Resource after Effective Lifetime\n\n## Description\n\nWhen a TCP connection using Netty\u0027s epoll transport has `ALLOW_HALF_CLOSURE` enabled (or is in a half-closed state via the HTTP codec), and the remote peer:\n\n1. Sends a FIN (half-close), causing the server to mark the input as shutdown, then\n2. Sends a RST (e.g. by closing with `SO_LINGER=0`)\n\nthe server-side channel is never closed. This happens because:\n\n- `epollOutReady()` is a no-op when there is no pending flush.\n- `epollInReady()` short-circuits via `shouldBreakEpollInReady()` because input is already marked as shutdown.\n- The `EPOLLERR`/`EPOLLHUP` error condition is therefore never processed, and `channelInactive` is never fired.\n\nDepending on the Netty version and configuration, this results in:\n\n- **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.\n- **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.\n\n## Mitigation\n\n- Upgrade to 4.2.13.Final when released (or build from the `4.2` branch at commit [`0ec3d97`](https://github.com/netty/netty/commit/0ec3d97fab376e243d328ac95fbd288ba0f6e22d)).\n- If upgrading is not immediately possible, configure idle timeouts on connections to limit the lifetime of stale channels.\n\n## References\n\n- Issue: https://github.com/netty/netty/issues/16683\n- Fix: https://github.com/netty/netty/pull/16689",
  "id": "GHSA-rwm7-x88c-3g2p",
  "modified": "2026-07-24T19:05:52Z",
  "published": "2026-05-06T23:10:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-rwm7-x88c-3g2p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42577"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/pull/16689"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/0ec3d97fab376e243d328ac95fbd288ba0f6e22d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty epoll transport denial of service via RST on half-closed TCP connection"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.