cbcvebase.
CVE-2024-47736
published 2024-10-21

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…

PriorityP422medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.18%
8.0th percentile
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.

Affected

18 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.11.2-1 (forky)linux 6.11.2-1 (forky)
linuxlinux
linuxlinux>= 8e6c8fa9f2e95c88a642521a5da19a8e31748846 < c1172e65aad4b115392ea4c6e61e56e5b9b69df4c1172e65aad4b115392ea4c6e61e56e5b9b69df4
linuxlinux>= 8e6c8fa9f2e95c88a642521a5da19a8e31748846 < 1bf7e414cac303c9aec1be67872e19be8b64980c1bf7e414cac303c9aec1be67872e19be8b64980c
linuxlinux>= 8e6c8fa9f2e95c88a642521a5da19a8e31748846 < b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8
linuxlinux>= 8e6c8fa9f2e95c88a642521a5da19a8e31748846 < 9cfa199bcbbbba31cbf97b2786f44f4464f3f29a9cfa199bcbbbba31cbf97b2786f44f4464f3f29a
linuxlinux>= 8e6c8fa9f2e95c88a642521a5da19a8e31748846 < 9e2f9d34dd12e6e5b244ec488bcebd0c2d566c509e2f9d34dd12e6e5b244ec488bcebd0c2d566c50
linuxlinux_kernel>= 0 < 6.11.2-16.11.2-1
linuxlinux_kernel>= 0 < 6.11.2-16.11.2-1
linuxlinux_kernel>= 0 < 6.8.0-60.636.8.0-60.63
linuxlinux_kernel>= 0 < 6.11.0-18.186.11.0-18.18
linuxlinux_kernel>= 5.13 < 6.10.136.10.13
linuxlinux_kernel>= 6.11 < 6.11.26.11.2
msrcazl3_kernel_6.6.76.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.92.2-1_on_azure_linux_3.0
msrccbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0
msrccbl2_kernel_5.15.200.1-1_on_cbl_mariner_2.0
msrccbl2_kernel_5.15.202.1-1_on_cbl_mariner_2.0

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv7.8HIGH
vendor_ubuntu7.8HIGH
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.