CVE-2023-53777

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: kill hooked chains to avoid loops on deduplicated compressed images<br /> <br /> After heavily stressing EROFS with several images which include a<br /> hand-crafted image of repeated patterns for more than 46 days, I found<br /> two chains could be linked with each other almost simultaneously and<br /> form a loop so that the entire loop won&amp;#39;t be submitted. As a<br /> consequence, the corresponding file pages will remain locked forever.<br /> <br /> It can be _only_ observed on data-deduplicated compressed images.<br /> For example, consider two chains with five pclusters in total:<br /> Chain 1: 2-&gt;3-&gt;4-&gt;5 -- The tail pcluster is 5;<br /> Chain 2: 5-&gt;1-&gt;2 -- The tail pcluster is 2.<br /> <br /> Chain 2 could link to Chain 1 with pcluster 5; and Chain 1 could link<br /> to Chain 2 at the same time with pcluster 2.<br /> <br /> Since hooked chains are all linked locklessly now, I have no idea how<br /> to simply avoid the race. Instead, let&amp;#39;s avoid hooked chains completely<br /> until I could work out a proper way to fix this and end users finally<br /> tell us that it&amp;#39;s needed to add it back.<br /> <br /> Actually, this optimization can be found with multi-threaded workloads<br /> (especially even more often on deduplicated compressed images), yet I&amp;#39;m<br /> not sure about the overall system impacts of not having this compared<br /> with implementation complexity.