GHSA-R62X-R6M8-28MX
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-05-27 15:33In the Linux kernel, the following vulnerability has been resolved:
ext4: fix dirtyclusters double decrement on fs shutdown
fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count:
WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]
Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks().
First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency.
To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.
{
"affected": [],
"aliases": [
"CVE-2026-45920"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:06Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix dirtyclusters double decrement on fs shutdown\n\nfstests test generic/388 occasionally reproduces a warning in\next4_put_super() associated with the dirty clusters count:\n\n WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]\n\nTracing the failure shows that the warning fires due to an\ns_dirtyclusters_counter value of -1. IOW, this appears to be a\nspurious decrement as opposed to some sort of leak. Further tracing\nof the dirty cluster count deltas and an LLM scan of the resulting\noutput identified the cause as a double decrement in the error path\nbetween ext4_mb_mark_diskspace_used() and the caller\next4_mb_new_blocks().\n\nFirst, note that generic/388 is a shutdown vs. fsstress test and so\nproduces a random set of operations and shutdown injections. In the\nproblematic case, the shutdown triggers an error return from the\next4_handle_dirty_metadata() call(s) made from\next4_mb_mark_context(). The changed value is non-zero at this point,\nso ext4_mb_mark_diskspace_used() does not exit after the error\nbubbles up from ext4_mb_mark_context(). Instead, the former\ndecrements both cluster counters and returns the error up to\next4_mb_new_blocks(). The latter falls into the !ar-\u003elen out path\nwhich decrements the dirty clusters counter a second time, creating\nthe inconsistency.\n\nTo avoid this problem and simplify ownership of the cluster\nreservation in this codepath, lift the counter reduction to a single\nplace in the caller. This makes it more clear that\next4_mb_new_blocks() is responsible for acquiring cluster\nreservation (via ext4_claim_free_clusters()) in the !delalloc case\nas well as releasing it, regardless of whether it ends up consumed\nor returned due to failure.",
"id": "GHSA-r62x-r6m8-28mx",
"modified": "2026-05-27T15:33:16Z",
"published": "2026-05-27T15:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45920"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3924aea2c33df3864929c1acd178bfc29d8f005f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/523d5a4df3c649fa305c89efb552ec62a1ce9d3d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55576fa14771d33994c29a9ae960e07bb3f56c20"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61e372122b6d95aec940fdaea0a16f988f359897"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81982a11406c5da6c6e2b188028e7056e16b7128"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94a8cea54cd935c54fa2fba70354757c0fc245e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca408af08544d96769c93a3d81a7f63f61129e95"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dbc4e10619ed87a50e637b96f2e574df36a7a769"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.