CVE-2026-46303

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.