Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
In the Linux kernel, the following vulnerability has been resolved:erofs: handle overlapped pclusters out of crafted images properlysyzbot reported a task hang issue due to a deadlock case where it iswaiting for the folio lock of a cached folio that will be used forcache I/Os.After looking into the crafted fuzzed image, I found it's formed withseveral 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 asup-to-date and then unlocked immediately (unlike in-place folios) whencompressed I/Os are complete. If physical blocks are not submitted inthe incremental order, there should be separate BIOs to avoid dependencyissues. 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 forefficient inter-queries. However, this is somewhat hard to implementeasily if overlapped big pclusters exist. Again, these only appear infuzzed images so let's simply fall back to temporary short-lived pagesfor correctness.Additionally, it justifies that referenced managed folios cannot betruncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidyup `struct z_erofs_bvec`") for simplicity although it shouldn't be anydifference.
No PoCs from references.
- https://github.com/fkie-cad/nvd-json-data-feeds
- https://github.com/oogasawa/Utility-security