CVE-2026-80879 Overview
CVE-2026-80879 is a circular locking dependency in the Linux kernel's Oracle Cluster File System 2 (OCFS2) implementation. The flaw resides in the ocfs2_dio_end_io_write() function within fs/ocfs2/aops.c. Three system inode locks participate in the cycle: INODE_ALLOC_SYSTEM_INODE, EXTENT_ALLOC_SYSTEM_INODE, and ORPHAN_DIR_SYSTEM_INODE. Kernel lockdep instrumentation detects the unsafe ordering and reports a possible deadlock. Under concurrent direct I/O completion, inode eviction, and ocfs2_mknod() operations, the mismatched acquisition order can cause a real deadlock that stalls filesystem activity.
Critical Impact
A deadlock in OCFS2 direct I/O completion paths can hang filesystem operations across cluster nodes, resulting in denial of service for workloads dependent on OCFS2 volumes.
Affected Products
- Linux kernel with OCFS2 filesystem support enabled
- Stable kernel branches referenced by the fix commits (137e8b48, 4273548e, 49b34bd3, ae1f3460, f0ae0a6c, f3dd1e53, ff187c50, ff6f26c5)
- Distributions shipping vulnerable OCFS2 modules prior to backporting the fix
Discovery Timeline
- 2026-09-04 - CVE-2026-80879 published to the National Vulnerability Database
- 2026-09-04 - Last updated in NVD database
Technical Details for CVE-2026-80879
Vulnerability Analysis
The defect is a lock-ordering violation classified as a race condition and deadlock issue in the OCFS2 direct I/O write completion path. ocfs2_dio_end_io_write() acquires the EXTENT_ALLOC system inode lock while processing unwritten extents. It then calls ocfs2_del_inode_from_orphan(), which attempts to acquire the ORPHAN_DIR inode lock while still holding EXTENT_ALLOC. This introduces a dependency EXTENT_ALLOC → ORPHAN_DIR.
Two other paths establish conflicting dependencies. ocfs2_mknod() acquires INODE_ALLOC before EXTENT_ALLOC during metadata allocation via ocfs2_reserve_new_metadata_blocks(). ocfs2_wipe_inode() acquires ORPHAN_DIR and then INODE_ALLOC through ocfs2_remove_inode() during ocfs2_evict_inode(). Combined, the chain INODE_ALLOC → EXTENT_ALLOC → ORPHAN_DIR → INODE_ALLOC forms a cycle. The EPSS score for this issue is 0.165%, reflecting low observed exploit interest.
Root Cause
The root cause is holding the EXTENT_ALLOC system inode lock across a call that acquires ORPHAN_DIR. This violates the global lock ordering established elsewhere in the OCFS2 subsystem. The upstream fix releases the allocation contexts (freeing EXTENT_ALLOC) in ocfs2_dio_end_io_write() before acquiring ORPHAN_DIR, breaking the cycle.
Attack Vector
The issue is triggered by legitimate filesystem workloads that combine direct I/O writes to unwritten extents, concurrent mknod operations, and inode eviction on the same OCFS2 volume. A local user with the ability to perform direct I/O and file creation on an OCFS2 filesystem can induce the conditions required for the deadlock. No network reachability or authentication bypass is involved. The impact is denial of service against tasks blocked on OCFS2 system inode locks.
No proof-of-concept exploit code is published. Refer to the kernel commit ae1f3460 for the corrective patch.
Detection Methods for CVE-2026-80879
Indicators of Compromise
- Kernel log entries containing WARNING: possible circular locking dependency detected referencing ocfs2_sysfile_lock_key classes
- Tasks stuck in D (uninterruptible sleep) state with stacks in ocfs2_evict_inode, ocfs2_del_inode_from_orphan, or ocfs2_reserve_suballoc_bits
- hung_task timeout warnings referencing OCFS2 direct I/O completion paths
Detection Strategies
- Enable CONFIG_PROVE_LOCKING in test kernels to surface lockdep splats that match the OCFS2 chain described in the advisory
- Correlate dmesg output with workloads performing direct I/O writes and concurrent mknod or unlink operations on OCFS2 volumes
- Track kernel version and OCFS2 module build against the fix commits referenced in the NVD advisory
Monitoring Recommendations
- Alert on repeated hung_task messages that name OCFS2 functions such as ocfs2_dio_end_io_write or ocfs2_wipe_inode
- Monitor filesystem availability metrics on OCFS2 clusters, including I/O latency spikes and stalled fsync operations
- Forward kernel logs from OCFS2 cluster members to a centralized data lake for cross-node correlation of lock warnings
How to Mitigate CVE-2026-80879
Immediate Actions Required
- Inventory all systems running OCFS2 and identify kernels that predate the fix commits
- Schedule kernel updates for affected hosts to a version that includes the upstream patches
- Restrict untrusted local access to OCFS2-backed mount points until patches are deployed
Patch Information
The fix modifies ocfs2_dio_end_io_write() to free the allocation contexts and release the EXTENT_ALLOC inode lock before acquiring ORPHAN_DIR. The change is available in the stable kernel commits 137e8b48, 4273548e, 49b34bd3, ae1f3460, f0ae0a6c, f3dd1e53, ff187c50, and ff6f26c5. Apply the vendor kernel update from your distribution once available.
Workarounds
- If OCFS2 is not required, unload the ocfs2 module and unmount OCFS2 volumes
- Reduce concurrency of direct I/O writers and metadata-heavy operations on OCFS2 volumes to lower the probability of triggering the cycle
- Blacklist the OCFS2 module on hosts that do not need cluster filesystem functionality
# Verify running kernel version and OCFS2 module status
uname -r
lsmod | grep ocfs2
# Temporary mitigation: unmount and unload OCFS2 where feasible
umount -a -t ocfs2
modprobe -r ocfs2
# Prevent module from loading until the patched kernel is installed
echo "blacklist ocfs2" > /etc/modprobe.d/ocfs2-blacklist.conf
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
