cbcvebase.
CVE-2024-38306
published 2024-06-25

CVE-2024-38306: In the Linux kernel, the following vulnerability has been resolved: btrfs: protect folio::private when attaching extent buffer folios [BUG] Since v6.8 there…

PriorityP416medium4.7CVSS 3.1
AVLACHPRLUINSUCNINAH
EPSS
0.15%
4.4th percentile
In the Linux kernel, the following vulnerability has been resolved: btrfs: protect folio::private when attaching extent buffer folios [BUG] Since v6.8 there are rare kernel crashes reported by various people, the common factor is bad page status error messages like this: BUG: Bad page state in process kswapd0 pfn:d6e840 page: refcount:0 mapcount:0 mapping:000000007512f4f2 index:0x2796c2c7c pfn:0xd6e840 aops:btree_aops ino:1 flags: 0x17ffffe0000008(uptodate|node=0|zone=2|lastcpupid=0x3fffff) page_type: 0xffffffff() raw: 0017ffffe0000008 dead000000000100 dead000000000122 ffff88826d0be4c0 raw: 00000002796c2c7c 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: non-NULL mapping [CAUSE] Commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to allocate-then-attach method") changes the sequence when allocating a new extent buffer. Previously we always called grab_extent_buffer() under mapping->i_private_lock, to ensure the safety on modification on folio::private (which is a pointer to extent buffer for regular sectorsize). This can lead to the following race: Thread A is trying to allocate an extent buffer at bytenr X, with 4 4K pages, meanwhile thread B is trying to release the page at X + 4K (the second page of the extent buffer at X). Thread A | Thread B -----------------------------------+------------------------------------- | btree_release_folio() | | This is for the page at X + 4K, | | Not page X. | | alloc_extent_buffer() | |- release_extent_buffer() |- filemap_add_folio() for the | | |- atomic_dec_and_test(eb->refs) | page at bytenr X (the first | | | | page). | | | | Which returned -EEXIST. | | | | | | | |- filemap_lock_folio() | | | | Returned the first page locked. | | | | | | | |- grab_extent_buffer() | | | | |- atomic_inc_not_zero() | | | | | Returned false | | | | |- folio_detach_private() | | |- folio_detach_private() for X | |- folio_test_private() | | |- folio_test_private() | Returned true | | | Returned true |- folio_

Affected

10 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.9.7-1 (forky)linux 6.9.7-1 (forky)
linuxlinux
linuxlinux>= 09e6cef19c9fc0e10547135476865b5272aa0406 < 952f048eb901881a7cc6f7c1368b53cd386ead7b952f048eb901881a7cc6f7c1368b53cd386ead7b
linuxlinux>= 09e6cef19c9fc0e10547135476865b5272aa0406 < f3a5367c679d31473d3fbb391675055b4792c309f3a5367c679d31473d3fbb391675055b4792c309
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.9.7-16.9.7-1
linuxlinux_kernel>= 0 < 6.9.7-16.9.7-1
linuxlinux_kernel>= 0 < 6.8.0-44.446.8.0-44.44
linuxlinux_kernel>= 6.8 < 6.9.56.9.5

CVSS provenance

nvdv3.14.7MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_ubuntu5.5MEDIUM
vendor_debian4.7LOW
vendor_redhat4.7MEDIUM
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.