CVE-2026-80879: ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix circular locking dependency in ocfs2dioendiowrite
A circular locking dependency involves INODEALLOCSYSTEMINODE, EXTENTALLOCSYSTEMINODE, and ORPHANDIRSYSTEMINODE.
1. ocfs2mknod() acquires INODEALLOC then EXTENTALLOC.
2. ocfs2dioendiowrite() acquires EXTENTALLOC for unwritten extents, then ORPHANDIR via ocfs2delinodefromorphan() while still holding EXTENTALLOC.
3. ocfs2wipeinode() acquires ORPHANDIR then INODEALLOC via ocfs2removeinode.
Break the cycle in ocfs2dioendiowrite() by freeing the allocation contexts (releasing EXTENTALLOC) before acquiring ORPHANDIR.
WARNING: possible circular locking dependency detected ------------------------------------------------------ is trying to acquire lock: ffff8881e78b33a0 (&ocfs2sysfilelockkey[INODEALLOCSYSTEMINODE]){+.+.}-{4:4}, at: ocfs2evictinode+0x1539/0x43b0 fs/ocfs2/inode.c:1299
but task is already holding lock: ffff8881e78b4fa0 (&ocfs2sysfilelockkey[ORPHANDIRSYSTEMINODE]){+.+.}-{4:4}, at: ocfs2evictinode+0xe97/0x43b0 fs/ocfs2/inode.c:1299
the existing dependency chain (in reverse order) is:
-> #2 (&ocfs2sysfilelockkey[ORPHANDIRSYSTEMINODE]){+.+.}-{4:4}: inodelock include/linux/fs.h:1029 [inline] ocfs2delinodefromorphan+0x12e/0x7a0 fs/ocfs2/namei.c:2728 ocfs2dioendio+0xf9c/0x1370 fs/ocfs2/aops.c:2418 diocomplete+0x25b/0x790 fs/direct-io.c:281
-> #1 (&ocfs2sysfilelockkey[EXTENTALLOCSYSTEMINODE]){+.+.}-{4:4}: inodelock include/linux/fs.h:1029 [inline] ocfs2reservesuballocbits+0x16d/0x4840 fs/ocfs2/suballoc.c:882 ocfs2reservenewmetadatablocks+0x415/0x9a0 fs/ocfs2/suballoc.c:1078 ocfs2mknod+0x10f3/0x2260 fs/ocfs2/namei.c:351
-> #0 (&ocfs2sysfilelockkey[INODEALLOCSYSTEMINODE]){+.+.}-{4:4}: lockacquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237 lockacquire+0x106/0x350 kernel/locking/lockdep.c:5868 downwrite+0x96/0x200 kernel/locking/rwsem.c:1625 inodelock include/linux/fs.h:1029 [inline] ocfs2removeinode fs/ocfs2/inode.c:733 [inline] ocfs2wipeinode fs/ocfs2/inode.c:896 [inline] ocfs2deleteinode fs/ocfs2/inode.c:1157 [inline] ocfs2evictinode+0x1539/0x43b0 fs/ocfs2/inode.c:1299
Chain exists of: &ocfs2sysfilelockkey[INODEALLOCSYSTEMINODE] --> &ocfs2sysfilelockkey[EXTENTALLOCSYSTEMINODE] --> &ocfs2sysfilelockkey[ORPHANDIRSYSTEMINODE]
Possible unsafe locking scenario:
CPU0 CPU1 ---- ---- lock(&ocfs2sysfilelockkey[ORPHANDIRSYSTEMINODE]); lock(&ocfs2sysfilelockkey[EXTENTALLOCSYSTEMINODE]); lock(&ocfs2sysfilelockkey[ORPHANDIRSYSTEMINODE]); lock(&ocfs2sysfilelockkey[INODEALLOCSYSTEMINODE]);
DEADLOCK
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel with the OCFS2 filesystem are relevant. The lock cycle involves OCFS2 inode allocation, extent allocation, and orphan-directory operations.
What operation triggers the circular locking dependency?
The problematic path occurs when ocfs2_dio_end_io_write handles unwritten extents and then removes an inode from the orphan directory while still holding the extent-allocation lock. Other OCFS2 paths establish the conflicting lock order.
How can administrators tell whether they are affected?
Kernel lock-dependency diagnostics can report a "possible circular locking dependency detected" warning involving OCFS2 system inode locks, including INODE_ALLOC_SYSTEM_INODE, EXTENT_ALLOC_SYSTEM_INODE, and ORPHAN_DIR_SYSTEM_INODE.
What is the remediation?
Apply a Linux kernel update containing the fix that releases the extent-allocation context before acquiring the orphan-directory lock in ocfs2_dio_end_io_write.