CVE-2026-97902: fs: don't return -EINVAL for successful nested thaw
In the Linux kernel, the following vulnerability has been resolved:
fs: don't return -EINVAL for successful nested thaw
Commit 7366f8b6fc6a ("fs: handle freezing from multiple devices") replaced the freezeholders bitmask with per-holder counters to allow nested freezes. In the bitmask version, a thaw that released a shared hold while another holder remained returned 0. Since the rework, thawsuperlocked() drops the freeze reference via freezedec() but then returns -EINVAL when other freezers remain, misinforming the caller: the thaw did succeed, the superblock just stays frozen for the remaining holders.
This breaks bdev-initiated freezing. When a filesystem is frozen with FIFREEZE and additionally frozen via bdevfreeze() -- which nests by design, see fsbdevfreeze() -- the subsequent bdevthaw() receives -EINVAL from the holder op although its freeze reference was dropped, and therefore keeps bdfsfreezecount elevated. Then device-mapper's unlockfs() ignores bdevthaw()'s return value, so nothing rebalances the count. After the user's FITHAW and umount, the block device can never be mounted again:
dm-1: Can't mount, blockdev is frozen
There is no way for userspace to drop the leaked count; only destroying the block device (or a reboot) recovers the device.
Reproducer (any kernel since v6.8):
dmsetup create dut --table "0 $(blockdev --getsz "$DEV") linear $DEV 0" mkfs.ext4 /dev/mapper/dut mount /dev/mapper/dut /mnt fsfreeze --freeze /mnt # freezeucount == 1 dmsetup suspend dut # bdfsfreezecount == 1, ucount == 2 dmsetup resume dut # ucount 2 -> 1, but thawsuper() # returns -EINVAL, so bdevthaw() # keeps bdfsfreezecount at 1 fsfreeze --unfreeze /mnt # filesystem thaws fine umount /mnt mount /dev/mapper/dut /mnt # EBUSY, forever
The same happens with fsfreeze held across an LVM snapshot of the origin volume.
fsbdevthaw()'s documentation already describes the intended semantics: "If this function returns zero it doesn't mean that the filesystem is unfrozen as it may have been frozen multiple times". Restore them by returning 0 when a nested thaw drops its hold while other freezers remain. Thawing without holding a freeze still fails with -EINVAL as mayunfreeze() rejects that case before the reference count is touched.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch 7366f8b6fc6a
Event History
Frequently Asked Questions
What sequence can leave a block device permanently frozen?
The issue occurs when a filesystem is frozen with FIFREEZE and also frozen through bdev_freeze(), which nests the freeze. A later bdev_thaw() drops its freeze reference but reports -EINVAL while another freezer remains; after the user performs FITHAW and unmounts, the device can remain frozen and cannot be mounted again.
Which environments are most directly affected?
Systems using device-mapper are directly implicated because its unlock_fs() ignores the bdev_thaw() return value, leaving bd_fsfreeze_count elevated. The described failure requires overlapping userspace FIFREEZE/FITHAW activity and block-device freezing.
How can administrators recognize the affected state?
After the described freeze, thaw, and unmount sequence, attempts to mount the block device fail because it remains frozen. The reported kernel message is "dm-1: Can't mount, blockdev is frozen".
Is there a userspace recovery once the device reaches this state?
No. The description states that userspace has no way to drop the remaining elevated freeze count after this sequence.