Description
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 freeze_holders 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,
thaw_super_locked() drops the freeze reference via freeze_dec() 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 bdev_freeze() -- which nests by
design, see fs_bdev_freeze() -- the subsequent bdev_thaw() receives
-EINVAL from the holder op although its freeze reference was dropped,
and therefore keeps bd_fsfreeze_count elevated. Then device-mapper's
unlock_fs() ignores bdev_thaw()'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 # freeze_ucount == 1
dmsetup suspend dut # bd_fsfreeze_count == 1, ucount == 2
dmsetup resume dut # ucount 2 -> 1, but thaw_super()
# returns -EINVAL, so bdev_thaw()
# keeps bd_fsfreeze_count 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.

fs_bdev_thaw()'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 may_unfreeze() rejects that case before the reference
count is touched.
Published: 2026-09-25
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service via permanently frozen block device
Action: Apply Patch
AI Analysis

Impact

The Linux kernel’s freeze/unfreeze logic has a logical error: when a nested thaw succeeds, the function returns -EINVAL instead of 0. This misleads callers into thinking the operation failed, but the freeze reference count remains elevated. Consequently, the affected block device stays in a frozen state and can never be mounted again, effectively locking the device and disrupting access to the filesystem. The flaw is a resource‑management error that leads to a permanent resource leak.

Affected Systems

All Linux kernel releases starting from 6.8 that have not yet applied commit 7366f8b6fc6a. The flaw lives in the core filesystem code and therefore affects every distribution that builds its kernel from this source tree, including mainstream distributions such as Ubuntu, Debian, CentOS, Fedora and others, until the protective commit is included.

Risk and Exploitability

An attacker capable of executing the freeze and thaw sequence can trigger the defect by using fsfreeze and device‑mapper calls that perform nested freeze/thaw operations. The defect is local in nature; no remote code execution or elevated privileges are required by the description, though the operations involved typically need the ability to perform device‑mapper commands. The CVSS score of 5.5 indicates moderate severity, and the EPSS score is < 1%, reflecting a very low likelihood of exploitation. The vulnerability is not listed in CISA’s KEV catalog. The impact is a denial‑of‑service that locks the block device until the system is rebooted or the device is recreated.

Generated by OpenCVE AI on October 1, 2026 at 06:55 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update your kernel to a revision that includes commit 7366f8b6fc6a, such as the latest stable release provided by your distribution’s security update channel.
  • If a block device becomes permanently frozen, reboot the system to reset freeze counts. If rebooting is not possible, delete the affected block device and recreate it to clear the leaky reference.
  • Avoid issuing nested freeze/thaw commands (for example, do not use fsfreeze together with bdev_freeze/bdev_thaw) until the kernel patch is applied.

Generated by OpenCVE AI on October 1, 2026 at 06:55 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Wed, 30 Sep 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-393
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low


Fri, 25 Sep 2026 23:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-399

Fri, 25 Sep 2026 10:30:00 +0000

Type Values Removed Values Added
Description 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 freeze_holders 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, thaw_super_locked() drops the freeze reference via freeze_dec() 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 bdev_freeze() -- which nests by design, see fs_bdev_freeze() -- the subsequent bdev_thaw() receives -EINVAL from the holder op although its freeze reference was dropped, and therefore keeps bd_fsfreeze_count elevated. Then device-mapper's unlock_fs() ignores bdev_thaw()'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 # freeze_ucount == 1 dmsetup suspend dut # bd_fsfreeze_count == 1, ucount == 2 dmsetup resume dut # ucount 2 -> 1, but thaw_super() # returns -EINVAL, so bdev_thaw() # keeps bd_fsfreeze_count 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. fs_bdev_thaw()'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 may_unfreeze() rejects that case before the reference count is touched.
Title fs: don't return -EINVAL for successful nested thaw
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-25T10:22:29.259Z

Reserved: 2026-09-25T10:18:58.200Z

Link: CVE-2026-97902

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-25T11:17:17.000

Modified: 2026-09-25T11:17:17.000

Link: CVE-2026-97902

cve-icon Redhat

Severity : Low

Publid Date: 2026-09-25T00:00:00Z

Links: CVE-2026-97902 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-01T07:00:03Z

Weaknesses