CVE-2026-80879

ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write

N/A
Published: September 4, 2026 at 04:49 PM UTC
Updated: September 4, 2026 at 05:36 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write A circular locking dependency involves INODE_ALLOC_SYSTEM_INODE, EXTENT_ALLOC_SYSTEM_INODE, and ORPHAN_DIR_SYSTEM_INODE. 1. ocfs2_mknod() acquires INODE_ALLOC then EXTENT_ALLOC. 2. ocfs2_dio_end_io_write() acquires EXTENT_ALLOC for unwritten extents, then ORPHAN_DIR via ocfs2_del_inode_from_orphan() while still holding EXTENT_ALLOC. 3. ocfs2_wipe_inode() acquires ORPHAN_DIR then INODE_ALLOC via ocfs2_remove_inode. Break the cycle in ocfs2_dio_end_io_write() by freeing the allocation contexts (releasing EXTENT_ALLOC) before acquiring ORPHAN_DIR. WARNING: possible circular locking dependency detected ------------------------------------------------------ is trying to acquire lock: ffff8881e78b33a0 (&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}, at: ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c:1299 but task is already holding lock: ffff8881e78b4fa0 (&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]){+.+.}-{4:4}, at: ocfs2_evict_inode+0xe97/0x43b0 fs/ocfs2/inode.c:1299 the existing dependency chain (in reverse order) is: -> #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 Chain exists of: &ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE] --> &ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE] --> &ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] Possible unsafe locking scenario: 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]); *** DEADLOCK ***

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v ≥ 7.0.45.10.258 ≤ v < 5.10.2615.15.209 ≤ v < 5.15.2126.1.175 ≤ v < 6.1.1786.12.86 ≤ v < 6.12.976.18.27 ≤ v < 6.18.406.6.140 ≤ v < 6.6.1457.0.4 ≤ v < 7.17.1 ≤ v < 7.1.57.1 ≤ v < 7.21e99bb19994246514d63e656492904176f9d5edd3c636a3edca9c3f180b3079f94fe7e115730d9c65.10.2585.15.2096.1.1756.12.866.18.276.6.14069c3fb310e9336cf48cfdf8748a32c29fd193d7.0.47.1886f97fa59d0bbfa9859fb1a66dd9e014b522d8991e05ac2336d00d5b99fc774be4bd5003908479697c03c0e9f73a5049794b3c69ee60fb5e8b0ebd8d647c5b2fbf81560818dacade360abc8c00a9665ea5bb1d20da756e4f41a48dad42b2e7d6e73f71e
Vendor states this is fixed in 137e8b4823a9a11928428d4ec0a0cacb2f50a769 (fixed)
Vendor states this is fixed in 4273548e418bd935430d35e9d052870f323441f3 (fixed)
Vendor states this is fixed in 49b34bd3ad69611af03590a23abf2cda9ac1073d (fixed)
Vendor states this is fixed in ae1f3460833d3e427420ab260278ec0e45d68c86 (fixed)
Vendor states this is fixed in f0ae0a6ca87dc2d4a789f71cdedb808ba6c16990 (fixed)
Vendor states this is fixed in f3dd1e534e9de64669415f8239e0094afecfed78 (fixed)
Vendor states this is fixed in ff187c502b39389b0d732cb7050a3db8e5ebfcd6 (fixed)
Vendor states this is fixed in ff6f26c58421614b02694ac9d219ac61d924bc68 (fixed)
Vendor states this is fixed in 5.10.261 (unaffected)
Vendor states this is fixed in 5.15.212 (unaffected)
Vendor states this is fixed in 6.1.178 (unaffected)
Vendor states this is fixed in 6.12.97 (unaffected)
Vendor states this is fixed in 6.18.40 (unaffected)
Vendor states this is fixed in 6.6.145 (unaffected)
Vendor states this is fixed in 7.1 (unaffected)
Vendor states this is fixed in 7.1.5 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card