CVE-2024-38306: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-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 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_put() | |- folio_put() Now there are two puts on the same folio at folio X, leading to refcount underflow of the folio X, and eventually causing the BUG_ON() on the page->mapping. The condition is not that easy to hit: - The release must be triggered for the middle page of an eb If the release is on the same first page of an eb, page lock would kick in and prevent the race. - folio_detach_private() has a very small race window It's only between folio_test_private() and folio_clear_private(). That's exactly when mapping->i_private_lock is used to prevent such race, and commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to allocate-then-attach method") screwed that up. At that time, I thought the page lock would kick in as filemap_release_folio() also requires the page to be locked, but forgot the filemap_release_folio() only locks one page, not all pages of an extent buffer. [FIX] Move all the code requiring i_private_lock into attach_eb_folio_to_filemap(), so that everything is done with proper lock protection. Furthermore to prevent future problems, add an extra lockdep_assert_locked() to ensure we're holding the proper lock. To reproducer that is able to hit the race (takes a few minutes with instrumented code inserting delays to alloc_extent_buffer()): #!/bin/sh drop_caches () { while(true); do echo 3 > /proc/sys/vm/drop_caches echo 1 > /proc/sys/vm/compact_memory done } run_tar () { while(true); do for x in `seq 1 80` ; do tar cf /dev/zero /mnt > /dev/null & done wait done } mkfs.btrfs -f -d single -m single ---truncated---

AI Analysis

Technical Summary

CVE-2024-38306 is a vulnerability in the Linux kernel's Btrfs filesystem implementation, specifically related to the handling of extent buffer folios. The issue arises from a race condition introduced by a kernel commit (09e6cef19c9f) that refactored the allocation method for extent buffers to an allocate-then-attach approach. Previously, the function grab_extent_buffer() was always called under the protection of mapping->i_private_lock, ensuring safe modification of folio::private, a pointer to the extent buffer for regular sector sizes. The refactoring inadvertently removed this lock protection during critical operations, creating a race window between two kernel threads: one allocating an extent buffer and another releasing a page within that buffer. This race can lead to a double put operation on the same folio, causing a reference count underflow and ultimately triggering a kernel BUG_ON() due to invalid page mapping state. The bug manifests as rare kernel crashes with bad page state errors, typically involving the kswapd0 process. The vulnerability is subtle and difficult to trigger because it requires a release operation on a middle page of an extent buffer and a very narrow race window between folio_test_private() and folio_clear_private(). The fix involves moving all code requiring i_private_lock into attach_eb_folio_to_filemap(), ensuring proper lock protection, and adding lockdep assertions to prevent future regressions. The vulnerability affects Linux kernel versions containing the problematic commit and is resolved in subsequent patches. No known exploits are reported in the wild, and no CVSS score has been assigned yet.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to systems running affected Linux kernel versions with Btrfs filesystems in use. The impact is mainly on system stability and availability, as the race condition can cause kernel crashes (BUG_ON) leading to system panics or reboots. This can disrupt critical services, especially in environments relying on Btrfs for storage management, such as cloud infrastructure, data centers, and enterprise servers. Confidentiality and integrity impacts are minimal since the flaw is a race condition causing crashes rather than unauthorized data access or modification. However, availability degradation can have cascading effects on business operations, particularly for organizations with high uptime requirements. The complexity and rarity of the race condition reduce the likelihood of widespread exploitation, but the potential for denial-of-service through kernel crashes remains a concern. European entities using Linux in production, especially those employing Btrfs for advanced storage features, should prioritize patching to maintain system reliability.

Mitigation Recommendations

1. Immediate application of the official Linux kernel patches that address this vulnerability is critical. Organizations should track kernel updates from their Linux distribution vendors and deploy them promptly. 2. For environments where immediate patching is challenging, consider temporarily avoiding workloads that heavily stress Btrfs extent buffer allocations and releases, such as intensive file operations or memory pressure scenarios that trigger kswapd activity. 3. Implement kernel crash monitoring and alerting to detect early signs of this issue, enabling rapid response and system recovery. 4. Use kernel lockdown or security modules to restrict untrusted code execution that might attempt to trigger the race condition. 5. Conduct thorough testing of kernel updates in staging environments to ensure stability before production deployment, given the complexity of kernel race conditions. 6. Maintain regular backups and disaster recovery plans to mitigate availability impacts from unexpected kernel crashes. 7. Engage with Linux distribution security advisories and community channels to stay informed about related vulnerabilities and fixes.