CVE-2024-47736

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: handle overlapped pclusters out of crafted images properly<br /> <br /> syzbot reported a task hang issue due to a deadlock case where it is<br /> waiting for the folio lock of a cached folio that will be used for<br /> cache I/Os.<br /> <br /> After looking into the crafted fuzzed image, I found it&amp;#39;s formed with<br /> several overlapped big pclusters as below:<br /> <br /> Ext: logical offset | length : physical offset | length<br /> 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384<br /> 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384<br /> 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384<br /> ...<br /> <br /> Here, extent 0/1 are physically overlapped although it&amp;#39;s entirely<br /> _impossible_ for normal filesystem images generated by mkfs.<br /> <br /> First, managed folios containing compressed data will be marked as<br /> up-to-date and then unlocked immediately (unlike in-place folios) when<br /> compressed I/Os are complete. If physical blocks are not submitted in<br /> the incremental order, there should be separate BIOs to avoid dependency<br /> issues. However, the current code mis-arranges z_erofs_fill_bio_vec()<br /> and BIO submission which causes unexpected BIO waits.<br /> <br /> Second, managed folios will be connected to their own pclusters for<br /> efficient inter-queries. However, this is somewhat hard to implement<br /> easily if overlapped big pclusters exist. Again, these only appear in<br /> fuzzed images so let&amp;#39;s simply fall back to temporary short-lived pages<br /> for correctness.<br /> <br /> Additionally, it justifies that referenced managed folios cannot be<br /> truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy<br /> up `struct z_erofs_bvec`") for simplicity although it shouldn&amp;#39;t be any<br /> difference.