Description (CNA)
In 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 (CNA)
| Vendor / product | Versions |
|---|---|
| Linux / Linux | affected 267f2492c8f71dac44399988b510f9bf6b074a51 before d3b39ea24835ac03da1a30f93ae7c05d55a40191; affected 267f2492c8f71dac44399988b510f9bf6b074a51 before b5b0d52f00e4bacb0ebdf47cd7016b0485fffad2; affected 267f2492c8f71dac44399988b510f9bf6b074a51 before 10c2b98a40d9044a3e97f4697ca6213bad7e19c2; affected 267f2492c8f71dac44399988b510f9bf6b074a51 before 967c28b23f6c89bb8eef6a046ea88afe0d7c1029 |
| Linux / Linux | affected 6.0; unaffected 0 before 6.0; unaffected 6.1.39 through 6.1.*; unaffected 6.3.13 through 6.3.*; unaffected 6.4.4 through 6.4.*; unaffected 6.5 through * |
CWE
No CWE identifiers supplied.