CVE-2026-31519: Linux Kernel Race Condition Vulnerability

CVE-2026-31519 Overview

A race condition vulnerability has been discovered in the Linux kernel's BTRFS filesystem implementation. The vulnerability exists in the subvolume creation process where the BTRFS_ROOT_ORPHAN_CLEANUP flag is not properly set during subvolume creation, leading to potential race conditions between orphan cleanup, delayed iput operations, and dentry cache management. This can result in broken dentries for valid subvolumes, causing filesystem operations to fail unexpectedly.

Critical Impact

Exploitation of this vulnerability can cause subvolumes to become inaccessible with broken dentries, prevent deletion of affected subvolumes, and potentially cause filesystem aborts when attempting to create new files or subvolumes over the corrupted entries.

Affected Products

• Linux kernel with BTRFS filesystem support
• Systems using BTRFS subvolumes

Discovery Timeline

• 2026-04-22 - CVE CVE-2026-31519 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-31519

Vulnerability Analysis

The vulnerability manifests in the interaction between BTRFS subvolume creation, orphan cleanup routines, and the Linux dentry cache. When a subvolume is created via create_subvol(), the function calls d_instantiate_new() but fails to set the BTRFS_ROOT_ORPHAN_CLEANUP bit on the root. This creates a window where subsequent lookups into the subvolume may trigger btrfs_orphan_cleanup() for the first time after the dentry cache has been dropped.

The race condition involves multiple concurrent operations: writeback processes that use igrab() on inodes, file unlink and close operations, delayed iput handling, and dentry cache lookups. When an ordered extent creation holds a reference via igrab() and the file is unlinked and closed while those references are held, the iput() in __dentry_kill() decrements i_count but does not trigger eviction due to the positive reference count. This allows the child dentry to be freed while the inode remains alive, and the subvolume dentry's d_lockref.count drops to zero, making it evictable.

Root Cause

The root cause is the missing BTRFS_ROOT_ORPHAN_CLEANUP flag setting during subvolume creation in create_subvol(). While btrfs_orphan_cleanup() uses test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) to ensure it only runs once per root, the initial subvolume creation path via d_instantiate_new() bypasses this mechanism. This allows a subsequent lookup after dentry cache eviction to make the first real call into btrfs_orphan_cleanup(), potentially racing with concurrent inode operations.

The call path that leads to the broken state is:

1. btrfs_lookup() calls btrfs_lookup_dentry()
2. btrfs_orphan_cleanup(sub_root) is invoked if filesystem is not read-only
3. test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) runs for the first time
4. btrfs_search_slot() may find orphan items concurrently being modified
5. Orphan cleanup fails with -ENOENT, printing "could not do orphan cleanup -2"
6. btrfs_lookup_dentry() returns -ENOENT
7. d_splice_alias(NULL, dentry) creates a negative dentry for a valid subvolume

Attack Vector

This vulnerability is triggered locally through filesystem operations on BTRFS subvolumes. An attacker or normal system operation could trigger the race condition by:

1. Creating a BTRFS subvolume
2. Creating files within the subvolume that generate ordered extents (triggering igrab() calls)
3. Unlinking and closing files while writeback operations hold inode references
4. Timing operations to cause dentry cache eviction during the race window

The resulting corrupted state causes ls operations to display broken dentries with question marks for permissions and ownership, stat operations to fail, subvolume deletion to fail with ENOENT, and attempts to create new files or subvolumes over the corrupted entry to fail with EEXIST and potentially abort the filesystem.

Detection Methods for CVE-2026-31519

Indicators of Compromise

• Kernel log messages containing "could not do orphan cleanup -2" indicating btrfs_orphan_cleanup() failures with ENOENT
• Directory listings showing entries with d????????? permissions and question marks for user, group, and size
• stat operations failing on BTRFS subvolumes that were previously accessible
• Subvolume operations returning unexpected ENOENT or EEXIST errors

Detection Strategies

• Monitor kernel logs (dmesg) for BTRFS orphan cleanup errors, specifically the pattern "could not do orphan cleanup"
• Implement filesystem health checks that periodically verify subvolume accessibility and dentry integrity
• Use btrfs check or btrfs scrub operations to detect filesystem inconsistencies
• Monitor for unusual combinations of ENOENT and EEXIST errors on the same filesystem paths

Monitoring Recommendations

• Configure log aggregation to alert on BTRFS-specific error messages in kernel logs
• Implement periodic automated checks of BTRFS subvolume health using btrfs subvolume list and verification scripts
• Monitor system call return values for BTRFS-mounted filesystems to detect patterns indicative of this race condition
• Track filesystem abort events which may occur when attempting operations on corrupted subvolume entries

How to Mitigate CVE-2026-31519

Immediate Actions Required

• Apply the kernel patches that set BTRFS_ROOT_ORPHAN_CLEANUP during subvolume creation
• If experiencing broken dentries, drop the dentry cache using echo 2 > /proc/sys/vm/drop_caches as a temporary workaround
• After clearing the dentry cache, affected subvolumes can be successfully deleted if removal is desired
• Plan for kernel upgrade to a patched version during the next maintenance window

Patch Information

Multiple kernel patches have been released to address this vulnerability. The fix involves setting the BTRFS_ROOT_ORPHAN_CLEANUP bit during subvolume creation to prevent the race condition. The following kernel commits contain the fix:

• Linux Kernel Commit 2ec578e
• Linux Kernel Commit 5131fa0
• Linux Kernel Commit 696683f
• Linux Kernel Commit a41a9b8
• Linux Kernel Commit c57276c
• Linux Kernel Commit d43da8d

Workarounds

• For systems exhibiting broken dentries, temporarily clear the dentry cache to restore access to affected subvolumes
• Reduce the likelihood of triggering the race by minimizing concurrent subvolume creation and heavy write workloads on the same filesystem
• Consider mounting affected BTRFS filesystems as read-only temporarily if data integrity is a primary concern until patches can be applied
• Monitor for affected subvolumes and restore access using dentry cache clearing before attempting administrative operations

# Workaround: Clear dentry cache to restore access to broken subvolumes
# WARNING: This affects all cached dentries system-wide
echo 2 > /proc/sys/vm/drop_caches

# Verify subvolume accessibility after clearing cache
btrfs subvolume list /path/to/btrfs/mount

# If subvolume is now accessible and no longer needed, delete it
btrfs subvolume delete /path/to/btrfs/mount/affected_subvol