Vulnerability-Lookup

GHSA-6XRQ-V3X4-XFC7

Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-10 15:33

Details

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] [ 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]

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().

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-68132"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-10T13:19:58Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsuper: fix emergency thaw deadlock on frozen block devices\n\ndo_thaw_all_callback() calls bdev_thaw() while holding sb-\u003es_umount\nexclusively. If the block device was frozen via bdev_freeze() dropping\nthe last block layer freeze reference calls fs_bdev_thaw() which\nreacquires s_umount:\n\n  do_thaw_all_callback(sb)\n    super_lock_excl(sb)                     # holds sb-\u003es_umount\n    bdev_thaw(sb-\u003es_bdev)\n      mutex_lock(\u0026bdev-\u003ebd_fsfreeze_mutex)\n      # bd_fsfreeze_count drops 1 -\u003e 0\n      bd_holder_ops-\u003ethaw == fs_bdev_thaw\n        get_bdev_super(bdev)\n          bdev_super_lock(bdev, true)\n            super_lock(sb, true)\n              down_write(\u0026sb-\u003es_umount)     # same task: deadlock\n\nThe emergency thaw worker deadlocks against itself holding both\ns_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount,\nfreeze, or thaw of that filesystem and block device.\n\n  [   81.878470] sysrq: Show Blocked State\n  [   81.880140] task:kworker/0:1     state:D stack:0     pid:11    tgid:11    ppid:2      task_flags:0x4208060 flags:0x00080000\n  [   81.884876] Workqueue: events do_thaw_all\n  [   81.886656] Call Trace:\n  [   81.887759]  \u003cTASK\u003e\n  [   81.888763]  __schedule+0x579/0x1420\n  [   81.890372]  schedule+0x3a/0x100\n  [   81.891794]  schedule_preempt_disabled+0x15/0x30\n  [   81.893848]  rwsem_down_write_slowpath+0x1ea/0x900\n  [   81.895191]  ? __pfx_do_thaw_all_callback+0x10/0x10\n  [   81.896528]  down_write+0xbd/0xc0\n  [   81.897505]  super_lock+0x91/0x180\n  [   81.898457]  ? __mutex_lock+0xa99/0x1140\n  [   81.900748]  ? __mutex_unlock_slowpath+0x1f/0x400\n  [   81.902069]  bdev_super_lock+0x5b/0x150\n  [   81.903132]  get_bdev_super+0x10/0x60\n  [   81.904042]  fs_bdev_thaw+0x23/0xf0\n  [   81.904755]  bdev_thaw+0x82/0x100\n  [   81.905484]  do_thaw_all_callback+0x2c/0x50\n  [   81.906298]  __iterate_supers+0x5d/0x130\n  [   81.907067]  do_thaw_all+0x20/0x40\n  [   81.907739]  process_one_work+0x206/0x5e0\n  [   81.908545]  worker_thread+0x1e2/0x3c0\n  [   81.909339]  ? __pfx_worker_thread+0x10/0x10\n  [   81.910171]  kthread+0xf4/0x130\n  [   81.910799]  ? __pfx_kthread+0x10/0x10\n  [   81.911528]  ret_from_fork+0x2e2/0x3b0\n  [   81.912259]  ? __pfx_kthread+0x10/0x10\n  [   81.913010]  ret_from_fork_asm+0x1a/0x30\n  [   81.913806]  \u003c/TASK\u003e\n\nbdev_super_lock() even documents the violated requirement with\nlockdep_assert_not_held(\u0026sb-\u003es_umount).\n\nAcquiring bd_fsfreeze_mutex under s_umount also inverts the\nbd_fsfreeze_mutex vs. s_umount ordering established by\nbdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer\nfreeze even when the recursive path isn\u0027t hit.\n\nFix this by not holding s_umount around the bdev_thaw() loop at all. Pin\nthe superblock with an active reference instead as\nfilesystems_freeze_callback() does. The active reference keeps the\nsuperblock from being shut down and so -\u003es_bdev stays valid without\nholding s_umount. The block-layer-held freeze is dropped by\nfs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as\na regular unfreeze would and thaw_super_locked() handles\nfilesystem-level freezes as before.\n\nThe emergency thaw path has deadlocked like this in one form or\nanother for a long long time but the current exclusively-held\nshape dates back to commit [1] where thaw_bdev() already ended in\nthaw_super() with s_umount held by do_thaw_all_callback().",
  "id": "GHSA-6xrq-v3x4-xfc7",
  "modified": "2026-08-10T15:33:37Z",
  "published": "2026-08-10T15:33:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68132"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4c483644d1a7709efe7d1be7dbf88cf4008a7864"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/63d78b546eefc38ad9898dc839bfc94811ede547"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/749d7aa0377aae32af8c0a4ad43371e7bf830ab5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

CVE-2026-68132 (GCVE-0-2026-68132)

Vulnerability from cvelistv5 – Published: 2026-08-10 11:58 – Updated: 2026-08-17 04:59

Title

super: fix emergency thaw deadlock on frozen block devices

Summary

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().

Severity

No CVSS data available.

Assigner

Linux mitre root

References

3 references

URL	Tags
https://git.kernel.org/stable/c/63d78b546eefc38ad…
https://git.kernel.org/stable/c/4c483644d1a7709ef…
https://git.kernel.org/stable/c/749d7aa0377aae32a…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 08fdc8a0138afaf324296a342f32ad26ec465e43 , < 63d78b546eefc38ad9898dc839bfc94811ede547 (git) Affected: 08fdc8a0138afaf324296a342f32ad26ec465e43 , < 4c483644d1a7709efe7d1be7dbf88cf4008a7864 (git) Affected: 08fdc8a0138afaf324296a342f32ad26ec465e43 , < 749d7aa0377aae32af8c0a4ad43371e7bf830ab5 (git)
Linux	Linux	Affected: 4.17 Unaffected: 0 , < 4.17 (semver) Unaffected: 6.18.42 , ≤ 6.18.* (semver) Unaffected: 7.1.6 , ≤ 7.1.* (semver) Unaffected: 7.2 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/super.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "63d78b546eefc38ad9898dc839bfc94811ede547",
              "status": "affected",
              "version": "08fdc8a0138afaf324296a342f32ad26ec465e43",
              "versionType": "git"
            },
            {
              "lessThan": "4c483644d1a7709efe7d1be7dbf88cf4008a7864",
              "status": "affected",
              "version": "08fdc8a0138afaf324296a342f32ad26ec465e43",
              "versionType": "git"
            },
            {
              "lessThan": "749d7aa0377aae32af8c0a4ad43371e7bf830ab5",
              "status": "affected",
              "version": "08fdc8a0138afaf324296a342f32ad26ec465e43",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/super.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.17"
            },
            {
              "lessThan": "4.17",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.42",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.42",
                  "versionStartIncluding": "4.17",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1.6",
                  "versionStartIncluding": "4.17",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2",
                  "versionStartIncluding": "4.17",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsuper: fix emergency thaw deadlock on frozen block devices\n\ndo_thaw_all_callback() calls bdev_thaw() while holding sb-\u003es_umount\nexclusively. If the block device was frozen via bdev_freeze() dropping\nthe last block layer freeze reference calls fs_bdev_thaw() which\nreacquires s_umount:\n\n  do_thaw_all_callback(sb)\n    super_lock_excl(sb)                     # holds sb-\u003es_umount\n    bdev_thaw(sb-\u003es_bdev)\n      mutex_lock(\u0026bdev-\u003ebd_fsfreeze_mutex)\n      # bd_fsfreeze_count drops 1 -\u003e 0\n      bd_holder_ops-\u003ethaw == fs_bdev_thaw\n        get_bdev_super(bdev)\n          bdev_super_lock(bdev, true)\n            super_lock(sb, true)\n              down_write(\u0026sb-\u003es_umount)     # same task: deadlock\n\nThe emergency thaw worker deadlocks against itself holding both\ns_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount,\nfreeze, or thaw of that filesystem and block device.\n\n  [   81.878470] sysrq: Show Blocked State\n  [   81.880140] task:kworker/0:1     state:D stack:0     pid:11    tgid:11    ppid:2      task_flags:0x4208060 flags:0x00080000\n  [   81.884876] Workqueue: events do_thaw_all\n  [   81.886656] Call Trace:\n  [   81.887759]  \u003cTASK\u003e\n  [   81.888763]  __schedule+0x579/0x1420\n  [   81.890372]  schedule+0x3a/0x100\n  [   81.891794]  schedule_preempt_disabled+0x15/0x30\n  [   81.893848]  rwsem_down_write_slowpath+0x1ea/0x900\n  [   81.895191]  ? __pfx_do_thaw_all_callback+0x10/0x10\n  [   81.896528]  down_write+0xbd/0xc0\n  [   81.897505]  super_lock+0x91/0x180\n  [   81.898457]  ? __mutex_lock+0xa99/0x1140\n  [   81.900748]  ? __mutex_unlock_slowpath+0x1f/0x400\n  [   81.902069]  bdev_super_lock+0x5b/0x150\n  [   81.903132]  get_bdev_super+0x10/0x60\n  [   81.904042]  fs_bdev_thaw+0x23/0xf0\n  [   81.904755]  bdev_thaw+0x82/0x100\n  [   81.905484]  do_thaw_all_callback+0x2c/0x50\n  [   81.906298]  __iterate_supers+0x5d/0x130\n  [   81.907067]  do_thaw_all+0x20/0x40\n  [   81.907739]  process_one_work+0x206/0x5e0\n  [   81.908545]  worker_thread+0x1e2/0x3c0\n  [   81.909339]  ? __pfx_worker_thread+0x10/0x10\n  [   81.910171]  kthread+0xf4/0x130\n  [   81.910799]  ? __pfx_kthread+0x10/0x10\n  [   81.911528]  ret_from_fork+0x2e2/0x3b0\n  [   81.912259]  ? __pfx_kthread+0x10/0x10\n  [   81.913010]  ret_from_fork_asm+0x1a/0x30\n  [   81.913806]  \u003c/TASK\u003e\n\nbdev_super_lock() even documents the violated requirement with\nlockdep_assert_not_held(\u0026sb-\u003es_umount).\n\nAcquiring bd_fsfreeze_mutex under s_umount also inverts the\nbd_fsfreeze_mutex vs. s_umount ordering established by\nbdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer\nfreeze even when the recursive path isn\u0027t hit.\n\nFix this by not holding s_umount around the bdev_thaw() loop at all. Pin\nthe superblock with an active reference instead as\nfilesystems_freeze_callback() does. The active reference keeps the\nsuperblock from being shut down and so -\u003es_bdev stays valid without\nholding s_umount. The block-layer-held freeze is dropped by\nfs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as\na regular unfreeze would and thaw_super_locked() handles\nfilesystem-level freezes as before.\n\nThe emergency thaw path has deadlocked like this in one form or\nanother for a long long time but the current exclusively-held\nshape dates back to commit [1] where thaw_bdev() already ended in\nthaw_super() with s_umount held by do_thaw_all_callback()."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-17T04:59:24.192Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/63d78b546eefc38ad9898dc839bfc94811ede547"
        },
        {
          "url": "https://git.kernel.org/stable/c/4c483644d1a7709efe7d1be7dbf88cf4008a7864"
        },
        {
          "url": "https://git.kernel.org/stable/c/749d7aa0377aae32af8c0a4ad43371e7bf830ab5"
        }
      ],
      "title": "super: fix emergency thaw deadlock on frozen block devices",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-68132",
    "datePublished": "2026-08-10T11:58:55.196Z",
    "dateReserved": "2026-07-30T09:28:09.370Z",
    "dateUpdated": "2026-08-17T04:59:24.192Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

GHSA-6XRQ-V3X4-XFC7

CVE-2026-68132 (GCVE-0-2026-68132)

Tags

Sightings

Nomenclature