Answer in brief
CVE-2026-68132 records a Unknown severity vulnerability in super: fix emergency thaw deadlock on frozen block devices. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=08fdc8a0138afaf324296a342f32ad26ec465e43 <63d78b546eefc38ad9898dc839bfc94811ede547 || >=08fdc8a0138afaf324296a342f32ad26ec465e43 <4c483644d1a7709efe7d1be7dbf88cf4008a7864 || >=08fdc8a0138afaf324296a342f32ad26ec465e43 <749d7aa0377aae32af8c0a4ad43371e7bf830ab5 | 63d78b546eefc38ad9898dc839bfc94811ede547, 4c483644d1a7709efe7d1be7dbf88cf4008a7864, 749d7aa0377aae32af8c0a4ad43371e7bf830ab5 |
| Linux/Linuxgeneric | 4.17 | Not reported |
| Linux/Linuxgeneric | >=08fdc8a0138afaf324296a342f32ad26ec465e43 <96248aeddde794227a49af1a332a1e21b3c15d56 || >=08fdc8a0138afaf324296a342f32ad26ec465e43 <c202aa03388fd1889b7aa4f7d677c49e22cd9700 || >=08fdc8a0138afaf324296a342f32ad26ec465e43 <2a1127c1c58b4f15a93f2fd56ff7c2c3d611d5c5 || >=08fdc8a0138afaf324296a342f32ad26ec465e43 <05536cad35f27b520d4b6f0e57c8cc5bfb6b0502 || >=08fdc8a0138afaf324296a342f32ad26ec465e43 <99719b5da9320ed344daee87d9c73d321a98f252 || >=08fdc8a0138afaf324296a342f32ad26ec465e43 <63d78b546eefc38ad9898dc839bfc94811ede547 || >=08fdc8a0138afaf324296a342f32ad26ec465e43 <4c483644d1a7709efe7d1be7dbf88cf4008a7864 || >=08fdc8a0138afaf324296a342f32ad26ec465e43 <749d7aa0377aae32af8c0a4ad43371e7bf830ab5 | 96248aeddde794227a49af1a332a1e21b3c15d56, c202aa03388fd1889b7aa4f7d677c49e22cd9700, 2a1127c1c58b4f15a93f2fd56ff7c2c3d611d5c5, 05536cad35f27b520d4b6f0e57c8cc5bfb6b0502, 99719b5da9320ed344daee87d9c73d321a98f252, 63d78b546eefc38ad9898dc839bfc94811ede547, 4c483644d1a7709efe7d1be7dbf88cf4008a7864, 749d7aa0377aae32af8c0a4ad43371e7bf830ab5 |
Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 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().
Quoted source text, attributed separately from HOL analysis.