CVE-2024-38306 — btrfs: protect folio::private when attaching extent buffer folios

Affected: Linux

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(…

Most recent entries from all

CVE-2024-38306 — btrfs: protect folio::private when attaching extent buffer folios