{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.19.11-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  ext4: handle wraparound when searching for blocks for indirect mapped blocks  Commit 4865c768b563 (\"ext4: always allocate blocks only from groups inode can use\") restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers.  However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern:     If ac-\u003eac_g_ex.fe_group is \u003e= ngroups (for instance, if the goal    group was populated via stream allocation from s_mb_last_groups),    then start will be \u003e= ngroups.     Does this allow allocating blocks beyond the 32-bit limit for    indirect block mapped files? The commit message mentions that    ext4_mb_scan_groups_linear() takes care to not select unsupported    groups. However, its loop uses group = *start, and the very first    iteration will call ext4_mb_scan_group() with this unsupported    group because next_linear_group() is only called at the end of the    iteration.  After reviewing the code paths involved and considering the LLM review, I determined that this can happen when there is a file system where some files/directories are extent-mapped and others are indirect-block mapped.  To address this, add a safety clamp in ext4_mb_scan_groups().",
  "id": "DEBIAN-CVE-2026-43067",
  "modified": "2026-09-14T16:47:38.472353826Z",
  "published": "2026-05-05T16:16:15.937Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-43067"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-43067"
  ]
}