CVE-2026-68132

What it actually does

This is a Linux kernel locking-order flaw in the emergency filesystem thaw path. When the kernel attempts to thaw all frozen filesystems, it can call the block-device thaw routine while already holding the superblock unmount lock. If the block-layer freeze reference count reaches zero, the thaw path re-enters code that tries to acquire the same superblock lock again, causing a self-deadlock. A related lock-order inversion between the block-device freeze mutex and the superblock unmount lock can also deadlock against concurrent freeze or thaw operations. The practical technical result is a kernel worker stuck in uninterruptible sleep, leaving the affected filesystem or block device unable to complete later unmount, freeze, or thaw operations.

Why it matters to the business

Successful exploitation or accidental triggering can cause operational disruption on Linux systems by leaving filesystems or block devices stuck in a frozen or partially thawed state. This can block unmounts, backups, snapshots, maintenance workflows, shutdowns, or storage failover operations and may require a reboot to recover cleanly. Because the issue is in kernel filesystem and block-device handling, the impact is availability-focused rather than data theft or remote code execution. The vulnerability is newly published, is not listed in CISA KEV, has no known ransomware association, and no public exploit maturity is indicated, but kernel deadlocks can still be high-impact on systems that rely on freeze/thaw for backup, snapshot, or storage orchestration.

How an attack unfolds

An attacker generally needs local access with sufficient privileges to interact with filesystem freeze/thaw or block-device freeze/thaw functionality, such as administrative capabilities normally required for snapshot or storage-management operations. The attacker first causes a filesystem or block device to enter a frozen state, then triggers the emergency thaw-all path while the relevant freeze reference state allows the block-device thaw operation to drop the final freeze reference. During that thaw, the kernel attempts to reacquire a superblock lock already held by the same execution path, or encounters an inverted lock ordering with another concurrent freeze/thaw operation. The responsible kernel worker then blocks indefinitely in uninterruptible sleep. Afterward, administrative operations involving the same filesystem or block device, including unmount, freeze, and thaw, may hang until the system is rebooted or otherwise recovered with a fixed kernel.

How to fix it

Apply a Linux kernel update from the operating system or distribution vendor that includes the emergency thaw deadlock fix. The corrected implementation avoids holding the superblock unmount lock around the block-device thaw loop and instead pins the superblock with an active reference. No exact fixed package versions were provided in the input, so remediation should be tracked through vendor kernel advisories and changelogs for the fix to the emergency thaw path involving do_thaw_all_callback(), bdev_thaw(), fs_bdev_thaw(), and s_umount locking. If immediate patching is not possible, reduce exposure by limiting local administrative access, restricting use of filesystem freeze/thaw operations to trusted automation, avoiding unnecessary emergency thaw operations, and scheduling maintenance windows for systems that heavily rely on filesystem snapshots or storage orchestration. A reboot may be required to recover systems already deadlocked and to load the patched kernel.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor backport or upstream fix for the emergency thaw deadlock. Validate by checking the installed kernel version against vendor security advisories, not only the upstream version number, because distributions often backport fixes. After patching and rebooting into the fixed kernel, verify that freeze/thaw, backup snapshot, unmount, and shutdown workflows complete normally on representative systems. Review kernel logs for absence of blocked-task traces involving do_thaw_all, do_thaw_all_callback, bdev_thaw, fs_bdev_thaw, super_lock, or rwsem_down_write_slowpath. If testing freeze/thaw behavior, perform it only in a controlled non-production environment because reproducing the flaw on an unfixed kernel can intentionally deadlock filesystem operations.

Typical attack path

1. Gain local access to a Linux system with privileges sufficient to issue filesystem or block-device freeze/thaw operations.
2. Freeze a filesystem or associated block device using legitimate administrative interfaces or storage-management tooling.
3. Trigger the kernel emergency thaw-all path, or race thaw-all activity against another freeze/thaw operation.
4. Cause the thaw path to call into block-device thaw while the superblock unmount lock is already held or while lock ordering is inverted.
5. Leave a kernel worker blocked in uninterruptible sleep while holding filesystem/block-device synchronization state.
6. Disrupt subsequent unmount, freeze, thaw, backup, snapshot, maintenance, or shutdown workflows for the affected filesystem or block device.

How to detect it

Look for evidence of kernel deadlock or hung filesystem operations rather than malware-style artifacts. Primary sources are kernel logs, system journal entries, hypervisor or console logs, crash dumps, and monitoring alerts for stuck unmount, freeze, thaw, backup, or snapshot jobs. Search for blocked-task reports showing a kworker thread in uninterruptible sleep in the do_thaw_all workqueue, especially stack traces containing do_thaw_all_callback, bdev_thaw, fs_bdev_thaw, get_bdev_super, bdev_super_lock, super_lock, down_write, or rwsem_down_write_slowpath. Also review operational logs from backup, snapshot, storage, and maintenance tooling for jobs that began filesystem freeze/thaw operations and then hung indefinitely. Because no public exploit maturity or named threat actor activity is indicated, treat findings as possible exploitation, misbehaving privileged automation, or accidental triggering until correlated with local authentication, sudo, audit, or process execution records showing who or what initiated freeze/thaw operations.

• Workqueue: events do_thaw_all
• do_thaw_all_callback
• bdev_thaw
• fs_bdev_thaw
• get_bdev_super
• bdev_super_lock
• super_lock
• down_write(&sb->s_umount)
• rwsem_down_write_slowpath
• bd_fsfreeze_mutex
• sysrq: Show Blocked State
• task:kworker/0:1 state:D
• state:D stack:0
• FREEZE_MAY_NEST
• FREEZE_HOLDER_USERSPACE

What your security team should do

• Prioritize patching Linux systems that use filesystem freeze/thaw for backups, snapshots, storage orchestration, virtualization platforms, databases, or maintenance automation.
• Inventory systems where privileged users, backup agents, storage agents, or orchestration tooling can call filesystem or block-device freeze/thaw operations.
• Monitor kernel logs for blocked kworker tasks and stack traces containing do_thaw_all_callback, bdev_thaw, fs_bdev_thaw, and s_umount-related locking.
• Restrict local administrative privileges and CAP_SYS_ADMIN-equivalent access to trusted users and services only.
• Coordinate with operations teams before testing or reproducing the condition, because triggering it can require reboot-based recovery.
• If a system shows the relevant deadlock symptoms, preserve kernel logs and blocked-task traces before rebooting where operationally feasible.
• Track vendor kernel advisories for exact fixed versions and ensure systems are rebooted into the fixed kernel after package installation.