Common Weakness Enumeration

CWE-835

Allowed

Loop with Unreachable Exit Condition ('Infinite Loop')

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.

1253 vulnerabilities reference this CWE, most recent first.

GHSA-4749-XQ6X-59V3

Vulnerability from github – Published: 2022-01-27 00:01 – Updated: 2022-02-04 00:00
VLAI
Details

Xerox VersaLink devices on specific versions of firmware before 2022-01-26 allow remote attackers to brick the device via a crafted TIFF file in an unauthenticated HTTP POST request. There is a permanent denial of service because image parsing causes a reboot, but image parsing is restarted as soon as the boot process finishes. However, this boot loop can be resolved by a field technician. The TIFF file must have an incomplete Image Directory. Affected firmware versions include xx.42.01 and xx.50.61. NOTE: the 2022-01-24 NeoSmart article included "believed to affect all previous and later versions as of the date of this posting" but a 2022-01-26 vendor statement reports "the latest versions of firmware are not vulnerable to this issue."

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-23968"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-26T06:15:00Z",
    "severity": "HIGH"
  },
  "details": "Xerox VersaLink devices on specific versions of firmware before 2022-01-26 allow remote attackers to brick the device via a crafted TIFF file in an unauthenticated HTTP POST request. There is a permanent denial of service because image parsing causes a reboot, but image parsing is restarted as soon as the boot process finishes. However, this boot loop can be resolved by a field technician. The TIFF file must have an incomplete Image Directory. Affected firmware versions include xx.42.01 and xx.50.61. NOTE: the 2022-01-24 NeoSmart article included \"believed to affect all previous and later versions as of the date of this posting\" but a 2022-01-26 vendor statement reports \"the latest versions of firmware are not vulnerable to this issue.\"",
  "id": "GHSA-4749-xq6x-59v3",
  "modified": "2022-02-04T00:00:46Z",
  "published": "2022-01-27T00:01:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23968"
    },
    {
      "type": "WEB",
      "url": "https://neosmart.net/blog/2022/xerox-vulnerability-allows-unauthenticated-network-users-to-remotely-brick-printers"
    },
    {
      "type": "WEB",
      "url": "https://twitter.com/mqudsi/status/1485756915187695618"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4846-7XWG-PW5M

Vulnerability from github – Published: 2026-07-21 12:33 – Updated: 2026-09-01 21:31
VLAI
Details

A flaw was found in libssh. A remote authenticated peer can advertise a zero maximum packet size in SSH_MSG_CHANNEL_OPEN, causing later channel writes to loop indefinitely and consume CPU, leading to denial of service.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-59843"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T12:18:57Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in libssh. A remote authenticated peer can advertise a zero maximum packet size in SSH_MSG_CHANNEL_OPEN, causing later channel writes to loop indefinitely and consume CPU, leading to denial of service.",
  "id": "GHSA-4846-7xwg-pw5m",
  "modified": "2026-09-01T21:31:13Z",
  "published": "2026-07-21T12:33:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59843"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:42922"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:55855"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:62217"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:62218"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-59843"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2498176"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4899-MPCH-38P3

Vulnerability from github – Published: 2026-08-20 18:43 – Updated: 2026-08-20 18:43
VLAI
Summary
netty-incubator-codec-ohttp BinaryHttpParser: Unauthenticated CPU-exhaustion DoS via infinite loop in field-section decoding
Details

BinaryHttpParser: Unauthenticated CPU-exhaustion DoS via infinite loop in field-section decoding

  • ID: BHTTP-LOOP-001
  • Severity: High
  • CVSS v3.1: 7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
  • CWE: CWE-835 (Loop with Unreachable Exit Condition) — secondary CWE-400 (Uncontrolled Resource Consumption)
  • Affected component: codec-bhttp → io.netty.incubator.codec.bhttp.BinaryHttpParser#readFieldSection, file codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:619-626
  • Affected version: netty-incubator-codec-ohttp HEAD d3f2b49 (release 0.0.22.Final + 3 commits). The loop has existed since the parser was introduced and is present in the latest code; all published advisory fixes are already applied.
  • Reachable from: io.netty.incubator.codec.ohttp.OHttpRequestResponseContext$ContentDecoder#decodeChunk (codec-ohttp/.../OHttpRequestResponseContext.java:214), i.e. the auto-wired OHTTP server and client codecs.
  • Confidence: High (empirically reproduced hang + thread dump against the unmodified parser).

Summary

BinaryHttpParser decodes Binary HTTP (RFC 9292) messages. An OHTTP gateway/client built on this library feeds the decrypted OHTTP body straight into BinaryHttpParser.parse(...). The field-section decoding loop terminates only on the exact condition fieldSectionLength != 0 and relies on a Java assert to guarantee forward progress. Because (a) the loop counter can be driven negative and (b) readFieldLine(...) legitimately consumes zero bytes and returns null on a truncated/over-long field line, the loop can spin forever. Assertions are disabled in any normal production JVM, so the two assert statements meant to catch this provide no protection.

A single ~17-byte Binary HTTP message — encapsulated by an unauthenticated attacker inside a normal OHTTP request, using the gateway's public key configuration — pins one Netty event-loop thread at 100% CPU permanently. A handful of such requests exhausts the entire event-loop group and takes the OHTTP gateway (or client) fully offline.

Root cause

BinaryHttpParser.java:619-626:

HeaderType lastType = HeaderType.PSEUDO_HEADER;
while (fieldSectionLength != 0) {            // 619  — "!= 0", not "> 0"
    int readableBytes = in.readableBytes();
    lastType = readFieldLine(in, headers, lastType, trailers);
    assert lastType != null;                 // 622  — no-op without -ea
    int read = readableBytes - in.readableBytes();
    assert read > 0;                         // 624  — no-op without -ea
    fieldSectionLength -= read;              // 625
}

Two cooperating defects:

  1. Counter can never hit zero. fieldSectionLength is the declared field-section byte length read from the wire (line 592). The loop subtracts the bytes each readFieldLine actually consumes. If a field line consumes more bytes than the (attacker-understated) declared length, fieldSectionLength goes negative and != 0 stays true forever.

  2. Zero-progress iterations. readFieldLine (lines 654-707) returns null without consuming any bytes when the remaining buffer cannot hold a complete field line — at lines 656, 664, 670, and 681 (the in.skipBytes(sumBytes) that advances the reader is only reached on the success path, line 705). When it returns null, read == 0, fieldSectionLength is unchanged, and the loop re-enters with identical state — a tight busy spin.

The only constructs that would have stopped either case are the assert statements on lines 622 and 624, which the JVM strips unless started with -ea. Production deployments do not run with assertions enabled.

Reachability (hop-by-hop, every guard resolved)

Attacker model: OHTTP gateways publish their HPKE key configuration so that any client can encrypt requests to them. The attacker therefore encrypts a malicious BHTTP body under the gateway's public key — a perfectly valid OHTTP request. HPKE decapsulation succeeds; the plaintext is attacker-chosen.

  1. OHttpServerCodec.decode → OHttpRequestResponseContext.parse → chunk decode → ContentDecoder.decodeChunk.
  2. OHttpRequestResponseContext.java:211 decrypts the chunk into decryptedChunk; line 212 cumulates it; line 214 calls binaryHttpParser.parse(binaryHttpCumulation, completeBodyReceived) — attacker-controlled plaintext, no application code in between.
  3. parse → READ_KNOWN_LENGTH_REQUEST_HEAD → readRequestHead (line 190).
  4. readRequestHead reads the control data, then at lines 445-451 slices all remaining readable bytes as the field section and calls readFieldSection(..., knownLength=true, maxFieldSectionSize).
  5. Inside readFieldSection:
  6. Guard checkFieldSectionTooLarge(fieldSectionLength, max) (line 607): bounds only the declared length, which the PoC sets to 1. Passes — not a barrier.
  7. Guard in.readableBytes() < sumBytes (line 609): sumBytes is built from the declared length, also tiny. Passes — not a barrier.
  8. Guards assert (lines 622, 624): no-ops in production. Defeated by default.
  9. Loop entered → spins forever (defects 1 + 2).

No reachable guard bounds the actual consumption or forces progress. maxFieldSectionSize is irrelevant because the declared length is small and the loop is CPU-bound on a fixed, small buffer (no allocation, no memory growth to trip any size cap).

Proof of concept (executed locally, benign liveness oracle)

The real codec-bhttp sources were compiled unmodified against netty 4.1.135.Final (the version pinned in pom.xml). The harness builds a valid known-length BHTTP request whose declared field-section length (0x01) is understated relative to the actual field line, then calls parse(in, true) on a worker thread with a 6-second watchdog. No payload, no side effects — purely a timing/CPU oracle.

Malicious message (17 bytes):

00 01 67 01 68 01 61 01 70 01 01 61 01 62 01 63 01
│  └method g └scheme h └auth a └path p │  └hdr a:b──┘ └ partial line
└ framing 0 (known-length request)     └ declared field-section length = 1

Observed (production default, assertions OFF):

[*] malicious BHTTP bytes (17): 0001670168016101700101610162016301
[!!] HANG CONFIRMED: parse() still running after 6000 ms
[!!] worker thread CPU time: 6029 ms (≈100% of one core => busy spin)
[!!] worker stack (top frames):
        at io.netty.incubator.codec.bhttp.BinaryHttpParser.readFieldSection(BinaryHttpParser.java:626)
        at io.netty.incubator.codec.bhttp.BinaryHttpParser.readRequestHead(BinaryHttpParser.java:451)
        at io.netty.incubator.codec.bhttp.BinaryHttpParser.parse(BinaryHttpParser.java:190)

CPU time ≈ wall time ⇒ a busy spin (RUNNABLE), not a blocked wait.

Controls: - Same input with -ea: parse() throws AssertionError at readFieldSection:624 immediately — proving the assertion is the only would-be guard and is absent in production. - Well-formed request (declared length matches): parse() returns DefaultBinaryHttpRequest promptly — proving the harness does not hang on valid input.

PoC sources: findings/netty-incubator-codec-ohttp/raw/Poc.java (hang + control 1) and raw/Poc2.java (negative control).

Impact

Unauthenticated, pre-business-logic remote denial of service. Each malicious request permanently consumes one Netty event-loop thread at 100% CPU. Netty event-loop groups have a small fixed thread count (default 2 × cores); a handful of requests exhausts every I/O thread, after which the gateway/client accepts no further connections and serves no traffic — a complete, persistent DoS that survives until process restart. Availability impact High; no confidentiality/integrity impact.

Adversarial re-reading (attempts to refute)

  • "maxFieldSectionSize caps it." No — the declared length in the PoC is 1; the cap (line 607) checks the declared value only. The spin happens on a 17-byte buffer with no allocation. Refutation fails.
  • "An upstream HTTP size limit / HttpObjectAggregator blocks it." No — the bug is CPU-bound, not memory-bound. The whole malicious message is tiny and well within any size limit. Refutation fails.
  • "This is just CVE-2024-40642 (absent input validation)." No — that advisory was about missing validation of method/scheme/authority/path enabling injection; that fix (the ALLOWED_TOKEN/ALLOWED_SCHEME validators, lines 76-122/461-466) is present and unrelated. This is a control-flow/termination defect in field-section length accounting. Distinct class, distinct code.
  • "The hang might be a harness artifact." No — the thread dump pinpoints readFieldSection:626; CPU≈wall confirms a spin; the -ea control throws at the exact assert; the well-formed control returns. The hang is for the claimed reason.
  • "completeBodyReceived must be true." Not required — the loop is inside readFieldSection, reached via readRequestHead once the control data is present, independent of that flag. The flag only affects a branch taken after readRequestHead returns null, which never happens here.

No concrete blocker survived. Verdict: CONFIRMED.

Remediation

  1. Change the loop exit condition to while (fieldSectionLength > 0) so an overshoot (negative counter) terminates.
  2. Treat a null / zero-progress return from readFieldLine while fieldSectionLength > 0 as a hard framing error — throw CorruptedFrameException("truncated or over-long field line") instead of re-looping.
  3. Reject any field line whose consumed byte count would drive fieldSectionLength below 0 (the declared length must be consumed exactly, per RFC 9292 §3.6).
  4. Do not rely on assert for wire-format invariants on attacker-controlled input; assertions are disabled in production. Promote lines 622/624 to explicit exceptions.

Example:

while (fieldSectionLength > 0) {
    int readableBytes = in.readableBytes();
    lastType = readFieldLine(in, headers, lastType, trailers);
    int read = readableBytes - in.readableBytes();
    if (lastType == null || read <= 0) {
        throw new CorruptedFrameException("truncated or over-long field line");
    }
    if (read > fieldSectionLength) {
        throw new CorruptedFrameException("field line exceeds declared field-section length");
    }
    fieldSectionLength -= read;
}

Notes

  • The indeterminate-length field-section path (framing indicators 2/3) shares the same loop and the same != 0 / zero-progress structure; the fix above should cover both. A dedicated trace of getIndeterminateLength (lines 538-566) under non-default maxFieldSectionSize is recorded separately as a lead.
  • Default maxFieldSectionSize for the OHTTP codecs is 8 * 1024 (OHttpCodecBuilder.DEFAULT_MAX_FIELD_SECTION_SIZE), and is irrelevant to this CPU-bound spin.
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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.0.22.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty.incubator:netty-incubator-codec-bhttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.23.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63202"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-20T18:43:38Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# BinaryHttpParser: Unauthenticated CPU-exhaustion DoS via infinite loop in field-section decoding\n\n- **ID:** BHTTP-LOOP-001\n- **Severity:** High\n- **CVSS v3.1:** 7.5 \u2014 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`\n- **CWE:** CWE-835 (Loop with Unreachable Exit Condition) \u2014 secondary CWE-400 (Uncontrolled Resource Consumption)\n- **Affected component:** `codec-bhttp` \u2192 `io.netty.incubator.codec.bhttp.BinaryHttpParser#readFieldSection`, file `codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:619-626`\n- **Affected version:** netty-incubator-codec-ohttp HEAD `d3f2b49` (release `0.0.22.Final` + 3 commits). The loop has existed since the parser was introduced and is present in the latest code; all published advisory fixes are already applied.\n- **Reachable from:** `io.netty.incubator.codec.ohttp.OHttpRequestResponseContext$ContentDecoder#decodeChunk` (`codec-ohttp/.../OHttpRequestResponseContext.java:214`), i.e. the auto-wired OHTTP server **and** client codecs.\n- **Confidence:** High (empirically reproduced hang + thread dump against the unmodified parser).\n\n## Summary\n\n`BinaryHttpParser` decodes Binary HTTP (RFC 9292) messages. An OHTTP gateway/client built on this library feeds the **decrypted** OHTTP body straight into `BinaryHttpParser.parse(...)`. The field-section decoding loop terminates only on the exact condition `fieldSectionLength != 0` and relies on a Java `assert` to guarantee forward progress. Because (a) the loop counter can be driven negative and (b) `readFieldLine(...)` legitimately consumes **zero** bytes and returns `null` on a truncated/over-long field line, the loop can spin forever. Assertions are disabled in any normal production JVM, so the two `assert` statements meant to catch this provide no protection.\n\nA single ~17-byte Binary HTTP message \u2014 encapsulated by an unauthenticated attacker inside a normal OHTTP request, using the gateway\u0027s **public** key configuration \u2014 pins one Netty event-loop thread at 100% CPU permanently. A handful of such requests exhausts the entire event-loop group and takes the OHTTP gateway (or client) fully offline.\n\n## Root cause\n\n`BinaryHttpParser.java:619-626`:\n\n```java\nHeaderType lastType = HeaderType.PSEUDO_HEADER;\nwhile (fieldSectionLength != 0) {            // 619  \u2014 \"!= 0\", not \"\u003e 0\"\n    int readableBytes = in.readableBytes();\n    lastType = readFieldLine(in, headers, lastType, trailers);\n    assert lastType != null;                 // 622  \u2014 no-op without -ea\n    int read = readableBytes - in.readableBytes();\n    assert read \u003e 0;                         // 624  \u2014 no-op without -ea\n    fieldSectionLength -= read;              // 625\n}\n```\n\nTwo cooperating defects:\n\n1. **Counter can never hit zero.** `fieldSectionLength` is the *declared* field-section byte length read from the wire (line 592). The loop subtracts the bytes each `readFieldLine` actually consumes. If a field line consumes more bytes than the (attacker-understated) declared length, `fieldSectionLength` goes negative and `!= 0` stays true forever.\n\n2. **Zero-progress iterations.** `readFieldLine` (lines 654-707) returns `null` **without consuming any bytes** when the remaining buffer cannot hold a complete field line \u2014 at lines 656, 664, 670, and 681 (the `in.skipBytes(sumBytes)` that advances the reader is only reached on the success path, line 705). When it returns `null`, `read == 0`, `fieldSectionLength` is unchanged, and the loop re-enters with identical state \u2014 a tight busy spin.\n\nThe only constructs that would have stopped either case are the `assert` statements on lines 622 and 624, which the JVM strips unless started with `-ea`. Production deployments do not run with assertions enabled.\n\n## Reachability (hop-by-hop, every guard resolved)\n\nAttacker model: OHTTP gateways publish their HPKE key configuration so that *any* client can encrypt requests to them. The attacker therefore encrypts a malicious BHTTP body under the gateway\u0027s public key \u2014 a perfectly valid OHTTP request. HPKE decapsulation succeeds; the plaintext is attacker-chosen.\n\n1. `OHttpServerCodec.decode` \u2192 `OHttpRequestResponseContext.parse` \u2192 chunk decode \u2192 `ContentDecoder.decodeChunk`.\n2. `OHttpRequestResponseContext.java:211` decrypts the chunk into `decryptedChunk`; line 212 cumulates it; **line 214** calls `binaryHttpParser.parse(binaryHttpCumulation, completeBodyReceived)` \u2014 attacker-controlled plaintext, no application code in between.\n3. `parse` \u2192 `READ_KNOWN_LENGTH_REQUEST_HEAD` \u2192 `readRequestHead` (line 190).\n4. `readRequestHead` reads the control data, then at lines 445-451 slices **all** remaining readable bytes as the field section and calls `readFieldSection(..., knownLength=true, maxFieldSectionSize)`.\n5. Inside `readFieldSection`:\n   - **Guard `checkFieldSectionTooLarge(fieldSectionLength, max)` (line 607):** bounds only the *declared* length, which the PoC sets to `1`. **Passes \u2014 not a barrier.**\n   - **Guard `in.readableBytes() \u003c sumBytes` (line 609):** `sumBytes` is built from the *declared* length, also tiny. **Passes \u2014 not a barrier.**\n   - **Guards `assert` (lines 622, 624):** no-ops in production. **Defeated by default.**\n   - Loop entered \u2192 spins forever (defects 1 + 2).\n\nNo reachable guard bounds the *actual* consumption or forces progress. `maxFieldSectionSize` is irrelevant because the declared length is small and the loop is CPU-bound on a fixed, small buffer (no allocation, no memory growth to trip any size cap).\n\n## Proof of concept (executed locally, benign liveness oracle)\n\nThe real `codec-bhttp` sources were compiled unmodified against netty `4.1.135.Final` (the version pinned in `pom.xml`). The harness builds a valid known-length BHTTP request whose declared field-section length (`0x01`) is understated relative to the actual field line, then calls `parse(in, true)` on a worker thread with a 6-second watchdog. No payload, no side effects \u2014 purely a timing/CPU oracle.\n\nMalicious message (17 bytes):\n```\n00 01 67 01 68 01 61 01 70 01 01 61 01 62 01 63 01\n\u2502  \u2514method g \u2514scheme h \u2514auth a \u2514path p \u2502  \u2514hdr a:b\u2500\u2500\u2518 \u2514 partial line\n\u2514 framing 0 (known-length request)     \u2514 declared field-section length = 1\n```\n\nObserved (production default, assertions OFF):\n```\n[*] malicious BHTTP bytes (17): 0001670168016101700101610162016301\n[!!] HANG CONFIRMED: parse() still running after 6000 ms\n[!!] worker thread CPU time: 6029 ms (\u2248100% of one core =\u003e busy spin)\n[!!] worker stack (top frames):\n        at io.netty.incubator.codec.bhttp.BinaryHttpParser.readFieldSection(BinaryHttpParser.java:626)\n        at io.netty.incubator.codec.bhttp.BinaryHttpParser.readRequestHead(BinaryHttpParser.java:451)\n        at io.netty.incubator.codec.bhttp.BinaryHttpParser.parse(BinaryHttpParser.java:190)\n```\nCPU time \u2248 wall time \u21d2 a busy spin (RUNNABLE), not a blocked wait.\n\nControls:\n- **Same input with `-ea`:** `parse()` throws `AssertionError` at `readFieldSection:624` immediately \u2014 proving the assertion is the only would-be guard and is absent in production.\n- **Well-formed request (declared length matches):** `parse()` returns `DefaultBinaryHttpRequest` promptly \u2014 proving the harness does not hang on valid input.\n\nPoC sources: `findings/netty-incubator-codec-ohttp/raw/Poc.java` (hang + control 1) and `raw/Poc2.java` (negative control).\n\n## Impact\n\nUnauthenticated, pre-business-logic remote denial of service. Each malicious request permanently consumes one Netty event-loop thread at 100% CPU. Netty event-loop groups have a small fixed thread count (default `2 \u00d7 cores`); a handful of requests exhausts every I/O thread, after which the gateway/client accepts no further connections and serves no traffic \u2014 a complete, persistent DoS that survives until process restart. Availability impact High; no confidentiality/integrity impact.\n\n## Adversarial re-reading (attempts to refute)\n\n- *\"`maxFieldSectionSize` caps it.\"* No \u2014 the declared length in the PoC is `1`; the cap (line 607) checks the declared value only. The spin happens on a 17-byte buffer with no allocation. Refutation fails.\n- *\"An upstream HTTP size limit / `HttpObjectAggregator` blocks it.\"* No \u2014 the bug is CPU-bound, not memory-bound. The whole malicious message is tiny and well within any size limit. Refutation fails.\n- *\"This is just CVE-2024-40642 (absent input validation).\"* No \u2014 that advisory was about missing validation of method/scheme/authority/path enabling injection; that fix (the `ALLOWED_TOKEN`/`ALLOWED_SCHEME` validators, lines 76-122/461-466) is present and unrelated. This is a control-flow/termination defect in field-section length accounting. Distinct class, distinct code.\n- *\"The hang might be a harness artifact.\"* No \u2014 the thread dump pinpoints `readFieldSection:626`; CPU\u2248wall confirms a spin; the `-ea` control throws at the exact assert; the well-formed control returns. The hang is for the claimed reason.\n- *\"`completeBodyReceived` must be true.\"* Not required \u2014 the loop is inside `readFieldSection`, reached via `readRequestHead` once the control data is present, independent of that flag. The flag only affects a branch taken *after* `readRequestHead` returns `null`, which never happens here.\n\nNo concrete blocker survived. Verdict: **CONFIRMED**.\n\n## Remediation\n\n1. Change the loop exit condition to `while (fieldSectionLength \u003e 0)` so an overshoot (negative counter) terminates.\n2. Treat a `null` / zero-progress return from `readFieldLine` while `fieldSectionLength \u003e 0` as a hard framing error \u2014 throw `CorruptedFrameException(\"truncated or over-long field line\")` instead of re-looping.\n3. Reject any field line whose consumed byte count would drive `fieldSectionLength` below 0 (the declared length must be consumed exactly, per RFC 9292 \u00a73.6).\n4. Do not rely on `assert` for wire-format invariants on attacker-controlled input; assertions are disabled in production. Promote lines 622/624 to explicit exceptions.\n\nExample:\n```java\nwhile (fieldSectionLength \u003e 0) {\n    int readableBytes = in.readableBytes();\n    lastType = readFieldLine(in, headers, lastType, trailers);\n    int read = readableBytes - in.readableBytes();\n    if (lastType == null || read \u003c= 0) {\n        throw new CorruptedFrameException(\"truncated or over-long field line\");\n    }\n    if (read \u003e fieldSectionLength) {\n        throw new CorruptedFrameException(\"field line exceeds declared field-section length\");\n    }\n    fieldSectionLength -= read;\n}\n```\n\n## Notes\n\n- The indeterminate-length field-section path (framing indicators 2/3) shares the same loop and the same `!= 0` / zero-progress structure; the fix above should cover both. A dedicated trace of `getIndeterminateLength` (lines 538-566) under non-default `maxFieldSectionSize` is recorded separately as a lead.\n- Default `maxFieldSectionSize` for the OHTTP codecs is `8 * 1024` (`OHttpCodecBuilder.DEFAULT_MAX_FIELD_SECTION_SIZE`), and is irrelevant to this CPU-bound spin.",
  "id": "GHSA-4899-mpch-38p3",
  "modified": "2026-08-20T18:43:38Z",
  "published": "2026-08-20T18:43:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty-incubator-codec-ohttp/security/advisories/GHSA-4899-mpch-38p3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty-incubator-codec-ohttp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty-incubator-codec-ohttp/releases/tag/netty-incubator-codec-parent-ohttp-0.0.23.Final"
    }
  ],
  "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-incubator-codec-ohttp BinaryHttpParser: Unauthenticated CPU-exhaustion DoS via infinite loop in field-section decoding"
}

GHSA-48MR-3PHH-9XCG

Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2025-04-20 03:33
VLAI
Details

An issue was discovered in ytnef before 1.9.1. This is related to a patch described as "2 of 9. Infinite Loop / DoS in the TNEFFillMapi function in lib/ytnef.c."

Severity
5.5 (Medium)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-6299"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-02-24T04:59:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in ytnef before 1.9.1. This is related to a patch described as \"2 of 9. Infinite Loop / DoS in the TNEFFillMapi function in lib/ytnef.c.\"",
  "id": "GHSA-48mr-3phh-9xcg",
  "modified": "2025-04-20T03:33:21Z",
  "published": "2022-05-13T01:46:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6299"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Yeraze/ytnef/pull/27"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LFJWMUEUC4ILH2HEOCYVVLQT654ZMCGQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LFJWMUEUC4ILH2HEOCYVVLQT654ZMCGQ"
    },
    {
      "type": "WEB",
      "url": "https://www.x41-dsec.de/lab/advisories/x41-2017-002-ytnef"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2017/dsa-3846"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2017/02/15/4"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96423"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-48R6-G3Q9-VPCP

Vulnerability from github – Published: 2022-05-13 01:17 – Updated: 2025-04-20 03:45
VLAI
Details

The ReadCAPTIONImage function in coders/caption.c in ImageMagick 7.0.7-3 allows remote attackers to cause a denial of service (infinite loop) via a crafted font file.

Severity
6.5 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-14741"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-26T02:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The ReadCAPTIONImage function in coders/caption.c in ImageMagick 7.0.7-3 allows remote attackers to cause a denial of service (infinite loop) via a crafted font file.",
  "id": "GHSA-48r6-g3q9-vpcp",
  "modified": "2025-04-20T03:45:53Z",
  "published": "2022-05-13T01:17:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14741"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick/issues/771"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00015.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3681-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4987-5P3P-9R27

Vulnerability from github – Published: 2023-08-11 15:30 – Updated: 2023-08-18 15:47
VLAI
Summary
FaucetSDN Ryu Denial of Service Vulnerability
Details

An issue was discovered in OFPBundleCtrlMsg in parser.py in FaucetSDN Ryu version 4.34, allows remote attackers to cause a denial of service (DoS) (infinite loop).

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": "PyPI",
        "name": "ryu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-35139"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-11T22:03:55Z",
    "nvd_published_at": "2023-08-11T14:15:11Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in `OFPBundleCtrlMsg` in `parser.py` in FaucetSDN Ryu version 4.34, allows remote attackers to cause a denial of service (DoS) (infinite loop).",
  "id": "GHSA-4987-5p3p-9r27",
  "modified": "2023-08-18T15:47:53Z",
  "published": "2023-08-11T15:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35139"
    },
    {
      "type": "WEB",
      "url": "https://github.com/faucetsdn/ryu/issues/118"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/faucetsdn/ryu"
    }
  ],
  "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": "FaucetSDN Ryu Denial of Service Vulnerability"
}

GHSA-49F9-3P9F-VGR4

Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44
VLAI
Details

Huawei DP300 V500R002C00; RP200 V500R002C00; V600R006C00; TE30 V100R001C10; V600R006C00; TE50 V600R006C00; TE60 V100R001C10; V500R002C00; V600R006C00; VP9660 V500R002C10 have an DoS vulnerability due to insufficient validation of the parameter when a putty comment key is loaded. An authenticated remote attacker can place a malformed putty key file in system when a system manager load the key an infinite loop happens which lead to reboot the system.

Severity
5.7 (Medium)
CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-17131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-03-05T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Huawei DP300 V500R002C00; RP200 V500R002C00; V600R006C00; TE30 V100R001C10; V600R006C00; TE50 V600R006C00; TE60 V100R001C10; V500R002C00; V600R006C00; VP9660 V500R002C10 have an DoS vulnerability due to insufficient validation of the parameter when a putty comment key is loaded. An authenticated remote attacker can place a malformed putty key file in system when a system manager load the key an infinite loop happens which lead to reboot the system.",
  "id": "GHSA-49f9-3p9f-vgr4",
  "modified": "2022-05-13T01:44:17Z",
  "published": "2022-05-13T01:44:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-17131"
    },
    {
      "type": "WEB",
      "url": "http://www.huawei.com/en/psirt/security-advisories/2017/huawei-sa-20171206-01-vpp-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-49Q3-9XM4-CPJ5

Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-09-06 00:00
VLAI
Details

hw/net/e1000e_core.c in QEMU 5.0.0 has an infinite loop via an RX descriptor with a NULL buffer address.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-28916"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-04T07:15:00Z",
    "severity": "MODERATE"
  },
  "details": "hw/net/e1000e_core.c in QEMU 5.0.0 has an infinite loop via an RX descriptor with a NULL buffer address.",
  "id": "GHSA-49q3-9xm4-cpj5",
  "modified": "2022-09-06T00:00:28Z",
  "published": "2022-05-24T17:35:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28916"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00024.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/09/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg03185.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/12/01/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4CCC-VVPW-P7R3

Vulnerability from github – Published: 2024-01-10 09:30 – Updated: 2024-01-18 18:30
VLAI
Details

MP4Box GPAC version 2.3-DEV-rev636-gfbd7e13aa-master was discovered to contain an infinite loop in the function av1_uvlc at media_tools/av_parsers.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted MP4 file.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-50120"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-10T09:15:44Z",
    "severity": "MODERATE"
  },
  "details": "MP4Box GPAC version 2.3-DEV-rev636-gfbd7e13aa-master was discovered to contain an infinite loop in the function av1_uvlc at media_tools/av_parsers.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted MP4 file.",
  "id": "GHSA-4ccc-vvpw-p7r3",
  "modified": "2024-01-18T18:30:23Z",
  "published": "2024-01-10T09:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50120"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gpac/gpac/issues/2698"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4CPQ-G6GC-93VR

Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53
VLAI
Details

In Long Range Zip (aka lrzip) 0.631, there is an infinite loop in the runzip_fd function of runzip.c. Remote attackers could leverage this vulnerability to cause a denial of service via a crafted lrz file.

Severity
5.5 (Medium)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-9058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-03-27T21:29:00Z",
    "severity": "MODERATE"
  },
  "details": "In Long Range Zip (aka lrzip) 0.631, there is an infinite loop in the runzip_fd function of runzip.c. Remote attackers could leverage this vulnerability to cause a denial of service via a crafted lrz file.",
  "id": "GHSA-4cpq-g6gc-93vr",
  "modified": "2022-05-13T01:53:50Z",
  "published": "2022-05-13T01:53:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9058"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ckolivas/lrzip/issues/93"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list