CVE-2026-68132 Overview
CVE-2026-68132 is a Linux kernel deadlock vulnerability in the superblock emergency thaw code path. The flaw resides in do_thaw_all_callback(), which calls bdev_thaw() while holding sb->s_umount exclusively. When the block device was previously frozen through bdev_freeze(), dropping the last block-layer freeze reference invokes fs_bdev_thaw(), which reacquires s_umount from the same task and deadlocks the worker.
The deadlock blocks the emergency thaw worker while it holds both s_umount and bd_fsfreeze_mutex, preventing any subsequent unmount, freeze, or thaw of the affected filesystem and block device.
Critical Impact
A frozen filesystem triggering emergency thaw enters a permanent deadlock, rendering the filesystem and its underlying block device unusable until reboot.
Affected Products
- Linux kernel (mainline) — superblock and block device thaw code path
- Stable kernel branches receiving backports referenced in the upstream commits
- Distribution kernels shipping the affected do_thaw_all_callback() implementation
Discovery Timeline
- 2026-08-10 - CVE-2026-68132 published to NVD
- 2026-08-10 - Last updated in NVD database
Technical Details for CVE-2026-68132
Vulnerability Analysis
The vulnerability is a self-deadlock in the Linux kernel's emergency thaw worker triggered through sysrq or equivalent paths that invoke do_thaw_all. The worker iterates over superblocks and calls do_thaw_all_callback(), which acquires sb->s_umount exclusively before calling bdev_thaw(sb->s_bdev).
Inside bdev_thaw(), the kernel takes bd_fsfreeze_mutex and decrements bd_fsfreeze_count. When the counter reaches zero, bd_holder_ops->thaw dispatches to fs_bdev_thaw(), which calls get_bdev_super() and then bdev_super_lock(). That path executes down_write(&sb->s_umount) on a lock the same task already holds, deadlocking the worker.
The kernel already documents this requirement with lockdep_assert_not_held(&sb->s_umount) inside bdev_super_lock(). Beyond the recursive deadlock, acquiring bd_fsfreeze_mutex under s_umount inverts the ordering established by bdev_freeze() and bdev_thaw(), creating an ABBA deadlock risk against concurrent block-layer freeze operations.
Root Cause
The root cause is incorrect lock scoping in do_thaw_all_callback(). Holding sb->s_umount across the bdev_thaw() call violates the documented lock ordering. The thaw path can re-enter the filesystem via fs_bdev_thaw(), which itself needs s_umount. This is a race condition and lock inversion issue [CWE-667 style locking flaw], present since the commit that reshaped emergency thaw around exclusively held s_umount.
Attack Vector
The deadlock is triggered locally through the emergency thaw path, typically via sysrq (Show Blocked State was observed in the kernel trace) or any code path invoking do_thaw_all while a filesystem's underlying block device retains a block-layer freeze reference. Exploitation requires the ability to freeze block devices and trigger emergency thaw, which is a privileged operation. The impact is denial of service against the affected filesystem and block device rather than code execution or privilege escalation.
The blocked task trace shows the worker stalled in rwsem_down_write_slowpath() under bdev_super_lock() invoked from fs_bdev_thaw() inside bdev_thaw(), confirming the recursive s_umount acquisition.
Detection Methods for CVE-2026-68132
Indicators of Compromise
- Kernel log entries showing Show Blocked State with a kworker task stuck in do_thaw_all and bdev_super_lock.
- Hung task warnings referencing fs_bdev_thaw, bdev_thaw, or do_thaw_all_callback in the call stack.
- Filesystems that cannot be unmounted, frozen, or thawed after an emergency thaw event.
Detection Strategies
- Monitor dmesg and kernel ring buffer output for hung_task warnings pointing at the thaw callback chain.
- Correlate sysrq events with subsequent filesystem operation failures on the same host.
- Track kernel version and patch level against the fixed commits referenced in the upstream advisory.
Monitoring Recommendations
- Enable hung_task_timeout_secs and forward kernel logs to a central logging pipeline for stalled-worker detection.
- Alert on repeated failures of umount, fsfreeze, or blkdiscard operations on production hosts.
- Track kernel package versions across the fleet to identify systems still running vulnerable builds.
How to Mitigate CVE-2026-68132
Immediate Actions Required
- Apply the upstream Linux kernel patches referenced in the git.kernel.org commits and reboot affected systems.
- Avoid invoking emergency thaw (sysrq-j or equivalent) on hosts running vulnerable kernels while filesystems are frozen via bdev_freeze().
- Audit tooling that issues fsfreeze or block-layer freezes to reduce exposure until patches are deployed.
Patch Information
The fix stops holding s_umount across the bdev_thaw() loop. Instead, the superblock is pinned with an active reference, mirroring the approach used in filesystems_freeze_callback(). The active reference keeps the superblock alive so ->s_bdev remains valid without holding s_umount, and fs_bdev_thaw() drops the block-layer freeze using FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE. See the upstream commits: 4c483644d1a7, 63d78b546eef, and 749d7aa0377a.
Workarounds
- Refrain from using sysrq emergency thaw on hosts with frozen block devices until the kernel is patched.
- Coordinate fsfreeze --unfreeze operations at the filesystem layer to avoid triggering the recursive block-layer thaw path.
- If a deadlock occurs, reboot the host; the stuck worker cannot be recovered without releasing s_umount, which is held by the deadlocked task.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
