CVE-2026-80528 in Linux
Resumen
por VulDB • 2026-08-26
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
ceph: evitar la recuperación del sistema de archivos (fs reclaim) mientras se utiliza `current->journal_info`
La función `handle_reply()` almacena un puntero a `ceph_mds_request` en `current->journal_info` mientras rellena la caché de inodos y entradas de directorio (dentry) a partir de una respuesta del MDS.
Una asignación en esta sección puede provocar una recuperación directa (direct reclaim) y podar dentries de otro sistema de archivos. Si esto ensucia un inode ext4, ext4 inicia una transacción JBD2. JBD2 interpreta la solicitud Ceph en `current->journal_info` como un manejador de registro (journal handle) y desreferencia el campo `r_tid` de la solicitud como `h_transaction`, lo que provoca un bloqueo del kernel, por ejemplo:
Unable to handle kernel paging request at virtual address 00000000077b4818 [...]
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in: CPU: 6 UID: 0 PID: 2699135 Comm: kworker/6:3 Tainted: G W 6.18.38-i3 #1113 NONE [...]
Workqueue: ceph-msgr ceph_con_workfn pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : jbd2__journal_start+0x2c/0x208 lr : __ext4_journal_start_sb+0x100/0x178 [...]
Call trace: jbd2__journal_start+0x2c/0x208 (P) __ext4_journal_start_sb+0x100/0x178 ext4_dirty_inode+0x3c/0x90 __mark_inode_dirty+0x58/0x400 iput.part.0+0x2b0/0x370 iput+0x18/0x30 dentry_unlink_inode+0xc0/0x158 __dentry_kill+0x80/0x250 shrink_dentry_list+0x90/0x130 prune_dcache_sb+0x60/0x98 super_cache_scan+0xe8/0x190 do_shrink_slab+0x174/0x388 shrink_slab+0xd8/0x4c0 shrink_node+0x31c/0x908 do_try_to_free_pages+0xd0/0x508 try_to_free_pages+0x11c/0x238 __alloc_frozen_pages_noprof+0x4d0/0xdd0 __folio_alloc_noprof+0x18/0x70 __filemap_get_folio+0x248/0x440 ceph_readdir_prepopulate+0x570/0x9e8 mds_dispatch+0x1424/0x1ba0 ceph_con_process_message+0x74/0xa0 ceph_con_v1_try_read+0x3a0/0x1510 ceph_con_workfn+0x260/0x460
Se debe entrar en un contexto de asignación NOFS con ámbito (scoped) y salir después de limpiar `journal_info`. Esto evita que la recuperación del sistema de archivos recursione hacia otro sistema de archivos mientras el campo contiene datos privados de Ceph.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.