CVE-2026-80879 in Linux
Resumen
por VulDB • 2026-09-04
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
ocfs2: corregir dependencia circular de bloqueo en ocfs2_dio_end_io_write
Una dependencia circular de bloqueo implica INODE_ALLOC_SYSTEM_INODE, EXTENT_ALLOC_SYSTEM_INODE y ORPHAN_DIR_SYSTEM_INODE.
1. ocfs2_mknod() adquiere INODE_ALLOC seguido de EXTENT_ALLOC.
2. ocfs2_dio_end_io_write() adquiere EXTENT_ALLOC para los extents no escritos, luego ORPHAN_DIR a través de ocfs2_del_inode_from_orphan() mientras aún mantiene EXTENT_ALLOC.
3. ocfs2_wipe_inode() adquiere ORPHAN_DIR seguido de INODE_ALLOC mediante ocfs2_remove_inode.
Romper el ciclo en ocfs2_dio_end_io_write() liberando los contextos de asignación (liberando EXTENT_ALLOC) antes de adquirir ORPHAN_DIR.
ADVERTENCIA: posible dependencia circular de bloqueo detectada ------------------------------------------------------ se está intentando adquirir el bloqueo: ffff8881e78b33a0 (&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}, en:
ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c:1299
pero la tarea ya está manteniendo el bloqueo: ffff8881e78b4fa0 (&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]){+.+.}-{4:4}, en:
ocfs2_evict_inode+0xe97/0x43b0 fs/ocfs2/inode.c:1299
la cadena de dependencia existente (en orden inverso) es:
-> #2 (&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]){+.+.}-{4:4}:
inode_lock include/linux/fs.h:1029 [inline]
ocfs2_del_inode_from_orphan+0x12e/0x7a0 fs/ocfs2/namei.c:2728 ocfs2_dio_end_io+0xf9c/0x1370 fs/ocfs2/aops.c:2418 dio_complete+0x25b/0x790 fs/direct-io.c:281
-> #1 (&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}:
inode_lock include/linux/fs.h:1029 [inline]
ocfs2_reserve_suballoc_bits+0x16d/0x4840 fs/ocfs2/suballoc.c:882 ocfs2_reserve_new_metadata_blocks+0x415/0x9a0 fs/ocfs2/suballoc.c:1078 ocfs2_mknod+0x10f3/0x2260 fs/ocfs2/namei.c:351
-> #0 (&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}:
__lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237 lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868 down_write+0x96/0x200 kernel/locking/rwsem.c:1625 inode_lock include/linux/fs.h:1029 [inline]
ocfs2_remove_inode fs/ocfs2/inode.c:733 [inline]
ocfs2_wipe_inode fs/ocfs2/inode.c:896 [inline]
ocfs2_delete_inode fs/ocfs2/inode.c:1157 [inline]
ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c:1299
La cadena existe de: &ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE] -->
&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE] -->
&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]
Posible escenario de bloqueo inseguro:
CPU0 CPU1 ---- ---- lock(&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]);
lock(&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]);
lock(&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]);
lock(&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]);
*** BLOQUEO MORTAL (DEADLOCK) ***
Once again VulDB remains the best source for vulnerability data.