Skip to main content

CVE-2024-26726: Vulnerability in Linux Linux

High
VulnerabilityCVE-2024-26726cvecve-2024-26726
Published: Wed Apr 03 2024 (04/03/2024, 14:55:24 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map. Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range. I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test.

AI-Powered Analysis

AILast updated: 06/29/2025, 17:55:22 UTC

Technical Analysis

CVE-2024-26726 is a vulnerability in the Linux kernel's Btrfs filesystem implementation, specifically related to handling the free space cache inode during write errors. The issue arises when the kernel attempts to write out the free space cache and encounters a write error. Normally, for regular files, the kernel drops the extent mapping upon a write failure, which is expected behavior. However, the free space cache inode is special and always expects the extent map to be valid. In this vulnerability, after the initial write error causes the extent map to be dropped, a subsequent attempt to write the space cache tries to retrieve the extent mapping again but finds none, resulting in an EXTENT_MAP_HOLE. This leads to a kernel panic due to an assertion failure in the Btrfs extent I/O code (fs/btrfs/extent_io.c at line 1385). The panic manifests as a BUG in the kernel, causing system instability and potential denial of service. The root cause is that the free space cache inode's extent map should not be dropped on write errors, unlike normal files. The fix involves skipping the dropping of the extent map range for the free space cache inode on write failure, preventing the panic. This vulnerability was discovered during continuous integration testing with error injection to reproduce the panic reliably. It affects Linux kernel versions around 6.8.0-rc2 and likely other versions using the affected Btrfs code. No known exploits are reported in the wild, and no CVSS score has been assigned yet. The vulnerability impacts the stability and availability of systems using Btrfs, particularly under error conditions affecting the free space cache write operations.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to systems running Linux with the Btrfs filesystem, which is increasingly used in enterprise and cloud environments for its advanced features like snapshots and checksumming. The kernel panic triggered by this flaw can cause unexpected system crashes, leading to denial of service and potential data unavailability. This is particularly critical for servers, storage appliances, and cloud infrastructure nodes relying on Btrfs for data integrity and performance. Organizations using Btrfs in production environments may face operational disruptions, impacting business continuity. While no direct data corruption is indicated, repeated crashes could increase the risk of data loss or complicate recovery efforts. The vulnerability does not require user interaction or authentication, meaning local processes or automated tasks that trigger writes to the free space cache could cause the panic. This increases the attack surface, especially in multi-tenant or shared environments. Although no exploits are known, the vulnerability's presence in the Linux kernel—a widely deployed OS in Europe—means that organizations should prioritize patching to maintain system stability and avoid service interruptions.

Mitigation Recommendations

1. Apply the official Linux kernel patches that address CVE-2024-26726 as soon as they become available from trusted sources or Linux distribution vendors. 2. Monitor kernel updates from distributions commonly used in your environment (e.g., Ubuntu, Debian, Red Hat, SUSE) and prioritize upgrades to versions including the fix. 3. If immediate patching is not possible, consider temporarily avoiding workloads or operations that heavily write to the Btrfs free space cache, such as disabling or limiting features that trigger frequent space cache writes. 4. Implement robust monitoring of system logs and kernel messages to detect early signs of Btrfs-related errors or panics, enabling proactive incident response. 5. Maintain regular backups and tested recovery procedures for systems using Btrfs to minimize data loss risk in case of crashes. 6. Evaluate the necessity of using Btrfs in critical systems; if stability is paramount and patching is delayed, consider alternative filesystems until the vulnerability is resolved. 7. Engage with Linux vendor support channels for guidance on backported patches or workarounds specific to your kernel version and distribution.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2024-02-19T14:20:24.163Z
Cisa Enriched
true
Cvss Version
null
State
PUBLISHED

Threat ID: 682d982ac4522896dcbe3959

Added to database: 5/21/2025, 9:08:58 AM

Last enriched: 6/29/2025, 5:55:22 PM

Last updated: 8/1/2025, 6:35:34 AM

Views: 15

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats