{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.176-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.88-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.7-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  isofs: validate Rock Ridge CE continuation extent against volume size  rock_continue() reads rs-\u003econt_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume.  commit e595447e177b (\"[PATCH] rock.c: handle corrupted directories\") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself.  commit f54e18f1b831 (\"isofs: Fix infinite looping over CE entries\") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.  With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs-\u003econt_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device.  sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation.  For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size.  Add an ISOFS_SB(sb)-\u003es_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.",
  "id": "DEBIAN-CVE-2026-46303",
  "modified": "2026-09-09T08:47:28.560831433Z",
  "published": "2026-06-08T17:16:48.853Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-46303"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-46303"
  ]
}