CVE-2024-47736

In the Linux kernel, the following vulnerability has been resolved:

erofs: handle overlapped pclusters out of crafted images properly

syzbot reported a task hang issue due to a deadlock case where it is

waiting for the folio lock of a cached folio that will be used for

cache I/Os.

After looking into the crafted fuzzed image, I found it's formed with

several overlapped big pclusters as below:

Ext: logical offset | length : physical offset | length

0: 0.. 16384 | 16384 : 151552.. 167936 | 16384

1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384

2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384

...

Here, extent 0/1 are physically overlapped although it's entirely

_impossible_ for normal filesystem images generated by mkfs.

First, managed folios containing compressed data will be marked as

up-to-date and then unlocked immediately (unlike in-place folios) when

compressed I/Os are complete. If physical blocks are not submitted in

the incremental order, there should be separate BIOs to avoid dependency

issues. However, the current code mis-arranges z_erofs_fill_bio_vec()

and BIO submission which causes unexpected BIO waits.

Second, managed folios will be connected to their own pclusters for

efficient inter-queries. However, this is somewhat hard to implement

easily if overlapped big pclusters exist. Again, these only appear in

fuzzed images so let's simply fall back to temporary short-lived pages

for correctness.

Additionally, it justifies that referenced managed folios cannot be

truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy

up `struct z_erofs_bvec`") for simplicity although it shouldn't be any

difference.