CVE-2026-68132

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> super: fix emergency thaw deadlock on frozen block devices<br /> <br /> do_thaw_all_callback() calls bdev_thaw() while holding sb-&gt;s_umount<br /> exclusively. If the block device was frozen via bdev_freeze() dropping<br /> the last block layer freeze reference calls fs_bdev_thaw() which<br /> reacquires s_umount:<br /> <br /> do_thaw_all_callback(sb)<br /> super_lock_excl(sb) # holds sb-&gt;s_umount<br /> bdev_thaw(sb-&gt;s_bdev)<br /> mutex_lock(&amp;bdev-&gt;bd_fsfreeze_mutex)<br /> # bd_fsfreeze_count drops 1 -&gt; 0<br /> bd_holder_ops-&gt;thaw == fs_bdev_thaw<br /> get_bdev_super(bdev)<br /> bdev_super_lock(bdev, true)<br /> super_lock(sb, true)<br /> down_write(&amp;sb-&gt;s_umount) # same task: deadlock<br /> <br /> The emergency thaw worker deadlocks against itself holding both<br /> s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount,<br /> freeze, or thaw of that filesystem and block device.<br /> <br /> [ 81.878470] sysrq: Show Blocked State<br /> [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000<br /> [ 81.884876] Workqueue: events do_thaw_all<br /> [ 81.886656] Call Trace:<br /> [ 81.887759] <br /> [ 81.888763] __schedule+0x579/0x1420<br /> [ 81.890372] schedule+0x3a/0x100<br /> [ 81.891794] schedule_preempt_disabled+0x15/0x30<br /> [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900<br /> [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10<br /> [ 81.896528] down_write+0xbd/0xc0<br /> [ 81.897505] super_lock+0x91/0x180<br /> [ 81.898457] ? __mutex_lock+0xa99/0x1140<br /> [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400<br /> [ 81.902069] bdev_super_lock+0x5b/0x150<br /> [ 81.903132] get_bdev_super+0x10/0x60<br /> [ 81.904042] fs_bdev_thaw+0x23/0xf0<br /> [ 81.904755] bdev_thaw+0x82/0x100<br /> [ 81.905484] do_thaw_all_callback+0x2c/0x50<br /> [ 81.906298] __iterate_supers+0x5d/0x130<br /> [ 81.907067] do_thaw_all+0x20/0x40<br /> [ 81.907739] process_one_work+0x206/0x5e0<br /> [ 81.908545] worker_thread+0x1e2/0x3c0<br /> [ 81.909339] ? __pfx_worker_thread+0x10/0x10<br /> [ 81.910171] kthread+0xf4/0x130<br /> [ 81.910799] ? __pfx_kthread+0x10/0x10<br /> [ 81.911528] ret_from_fork+0x2e2/0x3b0<br /> [ 81.912259] ? __pfx_kthread+0x10/0x10<br /> [ 81.913010] ret_from_fork_asm+0x1a/0x30<br /> [ 81.913806] <br /> <br /> bdev_super_lock() even documents the violated requirement with<br /> lockdep_assert_not_held(&amp;sb-&gt;s_umount).<br /> <br /> Acquiring bd_fsfreeze_mutex under s_umount also inverts the<br /> bd_fsfreeze_mutex vs. s_umount ordering established by<br /> bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer<br /> freeze even when the recursive path isn&amp;#39;t hit.<br /> <br /> Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin<br /> the superblock with an active reference instead as<br /> filesystems_freeze_callback() does. The active reference keeps the<br /> superblock from being shut down and so -&gt;s_bdev stays valid without<br /> holding s_umount. The block-layer-held freeze is dropped by<br /> fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as<br /> a regular unfreeze would and thaw_super_locked() handles<br /> filesystem-level freezes as before.<br /> <br /> The emergency thaw path has deadlocked like this in one form or<br /> another for a long long time but the current exclusively-held<br /> shape dates back to commit [1] where thaw_bdev() already ended in<br /> thaw_super() with s_umount held by do_thaw_all_callback().