CVE-2026-68150: Linux Kernel Race Condition Vulnerability

CVE-2026-68150 Overview

CVE-2026-68150 is a locking flaw in the Linux kernel's filesystem superblock subsystem (fs/super). The bug occurs during emergency thaw of frozen filesystems, where do_thaw_all() iterates over all superblocks and triggers a double-unlock of the s_umount reader-writer semaphore. This corrupts the rwsem state and triggers a DEBUG_RWSEMS_WARN_ON warning in kernel logs. The condition arises because __iterate_supers() acquires s_umount exclusively with SUPER_ITER_EXCL, while the callback do_thaw_all_callback() calls thaw_super_locked(), which also unconditionally releases the lock. The issue was resolved by switching to SUPER_ITER_UNLOCKED and letting the callback manage the lock itself.

Critical Impact
A double-unlock of s_umount corrupts rwsem state during emergency thaw operations, producing kernel warnings and potentially destabilizing filesystem locking on affected builds.

Affected Products

Linux kernel builds containing the affected __iterate_supers() / do_thaw_all() code path
Development kernels reporting as 7.2.0-rc4-00001-gbd3bd93ea98a
Systems where emergency thaw (sysrq) may be invoked against frozen filesystems

Discovery Timeline

2026-08-10 - CVE-2026-68150 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-68150

Vulnerability Analysis

The defect is a locking contract violation in the Linux kernel filesystem superblock code. do_thaw_all() is scheduled as a work item and iterates all superblocks using __iterate_supers() with the SUPER_ITER_EXCL flag. This flag instructs the iterator to acquire s_umount exclusively before invoking the callback and to release it after the callback returns.

The callback do_thaw_all_callback() invokes thaw_super_locked(), which unconditionally releases s_umount on every code path. When control returns to __iterate_supers(), the iterator releases s_umount a second time. This second up_write() operates on an already-released rwsem, corrupting the semaphore's internal state.

The corruption is detected by DEBUG_RWSEMS_WARN_ON in kernel/locking/rwsem.c:1412, which prints a warning showing the semaphore owner as 0x0 while curr points to the current task. The result is a kernel warning during any emergency thaw triggered from the SysRq handler.

Root Cause

The root cause is a mismatched locking convention between the iterator and its callback. __iterate_supers() with SUPER_ITER_EXCL assumes the callback will not drop s_umount. thaw_super_locked() documents the opposite contract, releasing the lock on every exit path. Combining these two produces a race-condition-adjacent double unlock of the same rwsem.

Attack Vector

Triggering the flaw requires initiating an emergency thaw of frozen filesystems, typically through the SysRq interface, which is a privileged local operation. The vulnerability manifests as rwsem state corruption and a kernel warning rather than remote exploitation. No verified proof-of-concept exploitation vector has been published. Refer to the upstream kernel commits for the exact code paths involved.

Detection Methods for CVE-2026-68150

Indicators of Compromise

Kernel log entries containing DEBUG_RWSEMS_WARN_ON and up_write+ originating from __iterate_supers and do_thaw_all
sysrq: Emergency Thaw of all frozen filesystems messages immediately preceding a rwsem warning
Warnings referencing kernel/locking/rwsem.c:1412 with count = 0x0 and a non-current owner value

Detection Strategies

Parse dmesg and journal logs for the signature stack trace: up_write → __iterate_supers → do_thaw_all → process_scheduled_works
Compare running kernel version and commit hash against the fixed commits 503d67fbaec6, 64017df6e61a, and c78e38745ff1
Alert on any SysRq-triggered emergency thaw events on production hosts, which are unusual in normal operations

Monitoring Recommendations

Forward kernel ring buffer output to a central log store and create rules matching rwsem debug warnings
Track workqueue events named do_thaw_all in kernel tracing infrastructure such as ftrace or perf
Baseline filesystem freeze and thaw activity so that emergency-thaw operations stand out for review

How to Mitigate CVE-2026-68150

Immediate Actions Required

Update to a Linux kernel build that includes the fix commits referenced in the stable kernel tree
Audit systems for custom kernels or backports that touch fs/super.c and verify they carry the corrected iterator flag
Restrict SysRq access on production systems where emergency thaw is not required for operations

Patch Information

The fix switches do_thaw_all() to use SUPER_ITER_UNLOCKED and acquires s_umount inside the callback via super_lock_excl() before calling thaw_super_locked(). This aligns the callback with the locking contract expected by thaw_super_locked() and removes the second up_write() in __iterate_supers(). The dead trailing return; in do_thaw_all_callback() was also removed. Fix commits: 503d67fbaec6, 64017df6e61a, and c78e38745ff1.

Workarounds

Avoid invoking echo j > /proc/sysrq-trigger or the equivalent emergency thaw path on affected kernels
Disable or mask the SysRq j function via kernel.sysrq sysctl to prevent unprivileged emergency thaw invocation
Rebuild kernels without CONFIG_DEBUG_RWSEMS only as a diagnostic-suppression measure; this hides the warning but does not fix the underlying corruption

bash

# Restrict SysRq to disable emergency thaw ('j') while preserving safe functions
# Bitmask reference: 1=enable-all, 0=disable-all; use a value that excludes bit 0x20 (sync/thaw)
sysctl -w kernel.sysrq=4
echo 'kernel.sysrq = 4' > /etc/sysctl.d/90-cve-2026-68150.conf

# Verify running kernel includes the fix
zgrep -E 'do_thaw_all|SUPER_ITER_UNLOCKED' /proc/config.gz 2>/dev/null
uname -r