CVE-2026-80536 in Linux
Riassunto
di VulDB • 26/08/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
xfs: controllo dei limiti del bitmap sporco dell'elemento di log del buffer
xlog_recover_do_reg_buffer() riproduce ogni regione sporca descritta dal bitmap dell'elemento di log nel buffer letto per tale elemento:
memcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), item->ri_buf[i].iov_base,
nbits << XFS_BLF_SHIFT);
L'offset di destinazione (bit/nbits, derivato dal bitmap sporco registrato) e le dimensioni del buffer (derivate da blf_len registrato) sono entrambe controllate dall'attaccante e altrimenti non correlate; tuttavia, l'unica cosa che limita la copia è un ASSERT(), il quale viene compilato via nei kernel di produzione. Un'immagine costruita ad hoc che registra un piccolo blf_len insieme a un bit del bitmap oltre la fine di tale buffer fa sì che memcpy() vada oltre l'allocazione del buffer, corrompendo lo heap del kernel adiacente durante il recupero del log in fase di mount. Questo è raggiungibile da chiunque possa far montare un'immagine costruita ad hoc: il modello di minaccia malicious-filesystem (filesystem malevolo) che XFS già protegge altrove.
Trasformare l'ASSERT() in una vera verifica XFS_IS_CORRUPT() che interrompe il recupero del buffer con -EFSCORRUPTED, coerente con l'idiooma validate-and-fail (valida e fallisci) già utilizzato in xlog_recover_do_inode_buffer() e xfs_dquot_item_recover.c. Di conseguenza, xlog_recover_do_reg_buffer() diventa STATIC int e i suoi tre chiamanti propagano l'errore.
Trovato e confermato con KASAN su una build CONFIG_XFS_DEBUG=n: l'immagine costruita ad hoc provoca una scrittura slab-out-of-bounds (fuori dai limiti dello slab) prima di questa modifica e fallisce il recupero in modo pulito con -EFSCORRUPTED dopo la modifica.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.