PT-2026-47374 · Linux · Linux

Published

2026-06-08

·

Updated

2026-06-08

·

CVE-2026-46303

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
isofs: validate Rock Ridge CE continuation extent against volume size
rock continue() reads rs->cont 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->cont 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)->s nzones bounds check to rock continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.

Related Identifiers

CVE-2026-46303

Affected Products

Linux