CVE-2026-46303

Published: Giu 08, 2026 Last Modified: Giu 08, 2026

ExploitDB:

Other exploit source:

Google Dorks:

Description

AI Translation Available

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.

AI Generated Translation

Nel kernel Linux, è stata risolta la seguente vulnerabilità:

isofs: convalidare l'estensione di continuazione Rock Ridge CE rispetto alla dimensione del volume

rock_continue() legge rs->cont_extent letteralmente dal record Rock Ridge CE e lo passa a sb_bread() senza verificare che il numero di blocco sia all’interno della dimensione del volume ISO 9660 montato. Il commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") ha aggiunto il rifiuto di cont_offset e cont_size per la continuazione CE, ma non ha validato il numero di blocco dell’estensione stessa. Successivamente, il commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") ha limitato la lunghezza della catena CE a RR_MAX_CE_ENTRIES = 32, ma ha nuovamente lasciato non verificato il numero di blocco.

Con un ISO appositamente manipolato montato tramite udisks2 (montaggio automatico ottico desktop) o tramite mount con CAP_SYS_ADMIN, rs->cont_extent può quindi puntare a un blocco fuori dal range o a blocchi appartenenti a un filesystem adiacente sullo stesso dispositivo a blocchi. La funzione sb_bread() su un blocco fuori dal range ritorna NULL in modo sicuro tramite il percorso EIO del layer dei blocchi, quindi non si verifica una violazione di sicurezza della memoria. Per le letture all’interno del range di dati del filesystem adiacente, il buffer CE viene analizzato come record Rock Ridge e solo il testo dei sotto-record SL raggiunge lo spazio utente tramite readlink(), il che rende il canale di perdita di informazioni stretto e difficile da sfruttare; comunque, rifiutare immediatamente il CE malformato corrisponde alla logica di rifiuto già presente nella stessa funzione per cont_offset e cont_size.

Viene aggiunto un controllo dei limiti ISOFS_SB(sb)->s_nzones in rock_continue() accanto alla verifica esistente di offset/dimensione, con la stampa della stessa notifica di directory entry corrotta.