CVE-2024-47736
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2024-47736
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-47736.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2024-47736
- Downstream
- Related
- Published
- 2024-10-21T12:14:06Z
- Modified
- 2025-10-17T14:12:03.172001Z
- Summary
- erofs: handle overlapped pclusters out of crafted images properly
- Details
-
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 zerofsfillbiovec() 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. - References
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- https://git.kernel.org/stable/c/1bf7e414cac303c9aec1be67872e19be8b64980c
- https://git.kernel.org/stable/c/9cfa199bcbbbba31cbf97b2786f44f4464f3f29a
- https://git.kernel.org/stable/c/9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50
- https://git.kernel.org/stable/c/b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced8e6c8fa9f2e95c88a642521a5da19a8e31748846Fixed1bf7e414cac303c9aec1be67872e19be8b64980c
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced8e6c8fa9f2e95c88a642521a5da19a8e31748846Fixedb9b30af0e86ffb485301ecd83b9129c9dfb7ebf8
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced8e6c8fa9f2e95c88a642521a5da19a8e31748846Fixed9cfa199bcbbbba31cbf97b2786f44f4464f3f29a
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced8e6c8fa9f2e95c88a642521a5da19a8e31748846Fixed9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50