{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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 -\u003e 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.",
  "id": "DEBIAN-CVE-2026-97902",
  "modified": "2026-09-26T04:47:39.294759377Z",
  "published": "2026-09-25T11:17:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-97902"
    }
  ],
  "upstream": [
    "CVE-2026-97902"
  ]
}