GHSA-V9MQ-Q8M3-5R3R
Vulnerability from github – Published: 2025-12-09 03:31 – Updated: 2025-12-09 03:31In the Linux kernel, the following vulnerability has been resolved:
erofs: kill hooked chains to avoid loops on deduplicated compressed images
After heavily stressing EROFS with several images which include a hand-crafted image of repeated patterns for more than 46 days, I found two chains could be linked with each other almost simultaneously and form a loop so that the entire loop won't be submitted. As a consequence, the corresponding file pages will remain locked forever.
It can be only observed on data-deduplicated compressed images. For example, consider two chains with five pclusters in total: Chain 1: 2->3->4->5 -- The tail pcluster is 5; Chain 2: 5->1->2 -- The tail pcluster is 2.
Chain 2 could link to Chain 1 with pcluster 5; and Chain 1 could link to Chain 2 at the same time with pcluster 2.
Since hooked chains are all linked locklessly now, I have no idea how to simply avoid the race. Instead, let's avoid hooked chains completely until I could work out a proper way to fix this and end users finally tell us that it's needed to add it back.
Actually, this optimization can be found with multi-threaded workloads (especially even more often on deduplicated compressed images), yet I'm not sure about the overall system impacts of not having this compared with implementation complexity.
{
"affected": [],
"aliases": [
"CVE-2023-53777"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-09T01:16:48Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: kill hooked chains to avoid loops on deduplicated compressed images\n\nAfter heavily stressing EROFS with several images which include a\nhand-crafted image of repeated patterns for more than 46 days, I found\ntwo chains could be linked with each other almost simultaneously and\nform a loop so that the entire loop won\u0027t be submitted. As a\nconsequence, the corresponding file pages will remain locked forever.\n\nIt can be _only_ observed on data-deduplicated compressed images.\nFor example, consider two chains with five pclusters in total:\n\tChain 1: 2-\u003e3-\u003e4-\u003e5 -- The tail pcluster is 5;\n Chain 2: 5-\u003e1-\u003e2 -- The tail pcluster is 2.\n\nChain 2 could link to Chain 1 with pcluster 5; and Chain 1 could link\nto Chain 2 at the same time with pcluster 2.\n\nSince hooked chains are all linked locklessly now, I have no idea how\nto simply avoid the race. Instead, let\u0027s avoid hooked chains completely\nuntil I could work out a proper way to fix this and end users finally\ntell us that it\u0027s needed to add it back.\n\nActually, this optimization can be found with multi-threaded workloads\n(especially even more often on deduplicated compressed images), yet I\u0027m\nnot sure about the overall system impacts of not having this compared\nwith implementation complexity.",
"id": "GHSA-v9mq-q8m3-5r3r",
"modified": "2025-12-09T03:31:10Z",
"published": "2025-12-09T03:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53777"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10c2b98a40d9044a3e97f4697ca6213bad7e19c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/967c28b23f6c89bb8eef6a046ea88afe0d7c1029"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5b0d52f00e4bacb0ebdf47cd7016b0485fffad2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d3b39ea24835ac03da1a30f93ae7c05d55a40191"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
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.