CVE-2026-68132 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
super: fix emergency thaw deadlock on frozen block devices
do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount:
do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock
The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device.
[ 81.878470] sysrq: Show Blocked State
[ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000
[ 81.884876] Workqueue: events do_thaw_all
[ 81.886656] Call Trace:
[ 81.887759] <TASK>
[ 81.888763] __schedule+0x579/0x1420
[ 81.890372] schedule+0x3a/0x100
[ 81.891794] schedule_preempt_disabled+0x15/0x30
[ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900
[ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10
[ 81.896528] down_write+0xbd/0xc0
[ 81.897505] super_lock+0x91/0x180
[ 81.898457] ? __mutex_lock+0xa99/0x1140
[ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400
[ 81.902069] bdev_super_lock+0x5b/0x150
[ 81.903132] get_bdev_super+0x10/0x60
[ 81.904042] fs_bdev_thaw+0x23/0xf0
[ 81.904755] bdev_thaw+0x82/0x100
[ 81.905484] do_thaw_all_callback+0x2c/0x50
[ 81.906298] __iterate_supers+0x5d/0x130
[ 81.907067] do_thaw_all+0x20/0x40
[ 81.907739] process_one_work+0x206/0x5e0
[ 81.908545] worker_thread+0x1e2/0x3c0
[ 81.909339] ? __pfx_worker_thread+0x10/0x10
[ 81.910171] kthread+0xf4/0x130
[ 81.910799] ? __pfx_kthread+0x10/0x10
[ 81.911528] ret_from_fork+0x2e2/0x3b0
[ 81.912259] ? __pfx_kthread+0x10/0x10
[ 81.913010] ret_from_fork_asm+0x1a/0x30
[ 81.913806] </TASK>
bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount).
Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer
freeze even when the recursive path isn't hit.
Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before.
The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in
thaw_super() with s_umount held by do_thaw_all_callback().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability represents a critical deadlock condition within the Linux kernel's filesystem freeze and thaw mechanisms, specifically affecting block device management during emergency thaw operations. The issue arises from improper lock ordering and resource management when transitioning between different kernel subsystems. The root cause lies in the interaction between superblock locking and block device freezing mutexes, creating a circular dependency that prevents system recovery. When the emergency thaw worker attempts to process frozen block devices, it holds exclusive access to the superblock's s_umount semaphore while simultaneously trying to acquire the block device's bd_fsfreeze_mutex. This creates an ABBA deadlock scenario where the same task holds both locks in opposite orders, leading to a complete system hang that blocks all subsequent filesystem operations.
The technical flaw manifests through a specific call chain involving do_thaw_all_callback() which initiates bdev_thaw() while maintaining exclusive superblock lock ownership. During this process, when the last block layer freeze reference is dropped, fs_bdev_thaw() is invoked, which attempts to reacquire the superblock's s_umount semaphore. This violates the documented lock ordering requirements as indicated by the lockdep_assert_not_held(&sb->s_umount) assertion that explicitly prohibits holding s_umount while acquiring bd_fsfreeze_mutex. The deadlock occurs because the same kernel thread holds both locks in conflicting orders, with the block device layer attempting to acquire s_umount while it's already held by the same thread. This scenario can be classified as a classic deadlock pattern and aligns with CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and ATT&CK technique T1486 (Data Encrypted for Ransom).
The operational impact of this vulnerability is severe as it renders the affected filesystem completely inaccessible until system reboot, since any subsequent freeze, thaw, or unmount operations on the impacted block device become impossible. The emergency thaw worker thread becomes stuck indefinitely, preventing normal system operation and potentially leading to data loss or service disruption in production environments. Systems relying on filesystem freeze operations for backup, snapshotting, or maintenance tasks are particularly vulnerable, as these operations can trigger the deadlock condition. The vulnerability has existed in various forms for an extended period but was exacerbated by a specific change in commit [1] that introduced the exclusive s_umount holding pattern during thaw operations.
The fix implements a proper isolation strategy by removing the requirement to hold s_umount throughout the bdev_thaw() loop entirely. Instead of maintaining superblock lock exclusivity, the solution uses an active reference mechanism similar to filesystems_freeze_callback() which keeps the superblock valid without requiring ongoing s_umount access. This approach allows fs_bdev_thaw() to release the block-layer-held freeze using the same mechanism as regular unfreeze operations with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE flags. The active reference ensures that s_bdev remains valid throughout the operation while avoiding the problematic lock ordering that caused the deadlock. This mitigation strategy addresses the fundamental synchronization issue by breaking the circular dependency between superblock and block device locking, effectively resolving the ABBA deadlock condition that was preventing system recovery. The fix maintains all existing functionality while eliminating the race condition that enabled the deadlock to occur in the first place.