CVE-2026-46303

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isofs: validate Rock Ridge CE continuation extent against volume size<br /> <br /> rock_continue() reads rs-&gt;cont_extent verbatim from the Rock Ridge CE<br /> record and passes it to sb_bread() without checking that the block<br /> number is within the mounted ISO 9660 volume. commit e595447e177b<br /> ("[PATCH] rock.c: handle corrupted directories") added cont_offset<br /> and cont_size rejection for the CE continuation but did not validate<br /> the extent block number itself. commit f54e18f1b831 ("isofs: Fix<br /> infinite looping over CE entries") later capped the CE chain length<br /> at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.<br /> <br /> With a crafted ISO mounted via udisks2 (desktop optical auto-mount)<br /> or via CAP_SYS_ADMIN mount, rs-&gt;cont_extent can therefore point at<br /> an out-of-range block or at blocks belonging to an adjacent<br /> filesystem on the same block device. sb_bread() on an out-of-range<br /> block returns NULL cleanly via the block layer EIO path, so there<br /> is no memory-safety violation. For in-range reads of adjacent-<br /> filesystem data, the CE buffer is parsed as Rock Ridge records and<br /> only the text of SL sub-records reaches userspace through<br /> readlink(), which makes the info-leak channel narrow and difficult<br /> to exploit; still, rejecting the malformed CE outright matches the<br /> rejection shape already present in the same function for<br /> cont_offset and cont_size.<br /> <br /> Add an ISOFS_SB(sb)-&gt;s_nzones bounds check to rock_continue() next<br /> to the existing offset/size rejection, printing the same<br /> corrupted-directory-entry notice.