CVE-2024-35798: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race in read_extent_buffer_pages() There are reports from tree-checker that detects corrupted nodes, without any obvious pattern so possibly an overwrite in memory. After some debugging it turns out there's a race when reading an extent buffer the uptodate status can be missed. To prevent concurrent reads for the same extent buffer, read_extent_buffer_pages() performs these checks: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) goto done; At this point, it seems safe to start the actual read operation. Once that completes, end_bbio_meta_read() does /* (3) */ set_extent_buffer_uptodate(eb); /* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags); Normally, this is enough to ensure only one read happens, and all other callers wait for it to finish before returning. Unfortunately, there is a racey interleaving: Thread A | Thread B | Thread C ---------+----------+--------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) When this happens, thread B kicks of an unnecessary read. Worse, thread C will see UPTODATE set and return immediately, while the read from thread B is still in progress. This race could result in tree-checker errors like this as the extent buffer is concurrently modified: BTRFS critical (device dm-0): corrupted node, root=256 block=8550954455682405139 owner mismatch, have 11858205567642294356 expect [256, 18446744073709551360] Fix it by testing UPTODATE again after setting the READING bit, and if it's been set, skip the unnecessary read. [ minor update of changelog ]
AI Analysis
Technical Summary
CVE-2024-35798 is a concurrency vulnerability in the Linux kernel's Btrfs filesystem implementation, specifically within the read_extent_buffer_pages() function. Btrfs uses extent buffers to manage metadata and data structures on disk. The vulnerability arises from a race condition when multiple threads concurrently read the same extent buffer. The function attempts to prevent concurrent reads by checking and setting flags indicating the buffer's read status (EXTENT_BUFFER_UPTODATE and EXTENT_BUFFER_READING). However, due to a racey interleaving of thread execution, a thread may incorrectly observe the buffer as up-to-date while another thread is still reading and modifying it. This leads to a scenario where multiple reads occur simultaneously, causing memory overwrites and corruption of the extent buffer's data structures. The corrupted metadata can manifest as errors detected by Btrfs tree-checker, such as corrupted nodes and owner mismatches. The root cause is that the code does not re-check the UPTODATE flag after setting the READING bit, allowing a stale view of the buffer's state. The fix involves adding a second check of the UPTODATE flag after setting the READING bit to avoid unnecessary concurrent reads. This vulnerability affects Linux kernel versions containing the specified commit (d7172f52e9933b6ec9305e7fe6e829e3939dba04) and potentially others with similar code. While no known exploits are reported in the wild, the issue can cause data corruption and filesystem instability under concurrent access conditions.
Potential Impact
For European organizations relying on Linux servers with Btrfs filesystems, this vulnerability poses a risk of data corruption and potential system instability. Btrfs is used in various enterprise and cloud environments for its advanced features like snapshots and checksumming. Corruption of filesystem metadata can lead to data loss, degraded system performance, and increased downtime due to filesystem repairs or restores. Critical infrastructure, financial institutions, and data centers using affected Linux kernels may experience operational disruptions. Since the vulnerability arises from concurrency in filesystem reads, workloads with high parallel I/O or multi-threaded access to Btrfs volumes are particularly vulnerable. Although exploitation does not appear to allow privilege escalation or remote code execution, the integrity and availability of data are at risk. This can impact compliance with data protection regulations such as GDPR if data loss or corruption affects personal data. The lack of known exploits reduces immediate threat but does not eliminate risk, especially in environments with heavy Btrfs usage.
Mitigation Recommendations
European organizations should prioritize updating Linux kernels to versions that include the patch fixing CVE-2024-35798. Since the vulnerability is in the kernel's Btrfs code, kernel upgrades are the primary mitigation. Organizations should: 1) Identify all systems using Btrfs filesystems and verify kernel versions against the fixed commit. 2) Test and deploy kernel updates in a controlled manner to avoid service disruption. 3) Implement monitoring for Btrfs filesystem errors and tree-checker warnings to detect early signs of corruption. 4) Regularly back up critical data stored on Btrfs volumes to enable recovery from corruption. 5) For high concurrency workloads, consider temporarily reducing parallel access to Btrfs volumes until patches are applied. 6) Engage with Linux distribution vendors for timely security updates and advisories. 7) Review and harden system configurations to limit unnecessary multi-threaded filesystem access where feasible. These steps go beyond generic advice by focusing on filesystem-specific monitoring and workload adjustments.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Denmark, Norway, Belgium, Italy
CVE-2024-35798: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race in read_extent_buffer_pages() There are reports from tree-checker that detects corrupted nodes, without any obvious pattern so possibly an overwrite in memory. After some debugging it turns out there's a race when reading an extent buffer the uptodate status can be missed. To prevent concurrent reads for the same extent buffer, read_extent_buffer_pages() performs these checks: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) goto done; At this point, it seems safe to start the actual read operation. Once that completes, end_bbio_meta_read() does /* (3) */ set_extent_buffer_uptodate(eb); /* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags); Normally, this is enough to ensure only one read happens, and all other callers wait for it to finish before returning. Unfortunately, there is a racey interleaving: Thread A | Thread B | Thread C ---------+----------+--------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) When this happens, thread B kicks of an unnecessary read. Worse, thread C will see UPTODATE set and return immediately, while the read from thread B is still in progress. This race could result in tree-checker errors like this as the extent buffer is concurrently modified: BTRFS critical (device dm-0): corrupted node, root=256 block=8550954455682405139 owner mismatch, have 11858205567642294356 expect [256, 18446744073709551360] Fix it by testing UPTODATE again after setting the READING bit, and if it's been set, skip the unnecessary read. [ minor update of changelog ]
AI-Powered Analysis
Technical Analysis
CVE-2024-35798 is a concurrency vulnerability in the Linux kernel's Btrfs filesystem implementation, specifically within the read_extent_buffer_pages() function. Btrfs uses extent buffers to manage metadata and data structures on disk. The vulnerability arises from a race condition when multiple threads concurrently read the same extent buffer. The function attempts to prevent concurrent reads by checking and setting flags indicating the buffer's read status (EXTENT_BUFFER_UPTODATE and EXTENT_BUFFER_READING). However, due to a racey interleaving of thread execution, a thread may incorrectly observe the buffer as up-to-date while another thread is still reading and modifying it. This leads to a scenario where multiple reads occur simultaneously, causing memory overwrites and corruption of the extent buffer's data structures. The corrupted metadata can manifest as errors detected by Btrfs tree-checker, such as corrupted nodes and owner mismatches. The root cause is that the code does not re-check the UPTODATE flag after setting the READING bit, allowing a stale view of the buffer's state. The fix involves adding a second check of the UPTODATE flag after setting the READING bit to avoid unnecessary concurrent reads. This vulnerability affects Linux kernel versions containing the specified commit (d7172f52e9933b6ec9305e7fe6e829e3939dba04) and potentially others with similar code. While no known exploits are reported in the wild, the issue can cause data corruption and filesystem instability under concurrent access conditions.
Potential Impact
For European organizations relying on Linux servers with Btrfs filesystems, this vulnerability poses a risk of data corruption and potential system instability. Btrfs is used in various enterprise and cloud environments for its advanced features like snapshots and checksumming. Corruption of filesystem metadata can lead to data loss, degraded system performance, and increased downtime due to filesystem repairs or restores. Critical infrastructure, financial institutions, and data centers using affected Linux kernels may experience operational disruptions. Since the vulnerability arises from concurrency in filesystem reads, workloads with high parallel I/O or multi-threaded access to Btrfs volumes are particularly vulnerable. Although exploitation does not appear to allow privilege escalation or remote code execution, the integrity and availability of data are at risk. This can impact compliance with data protection regulations such as GDPR if data loss or corruption affects personal data. The lack of known exploits reduces immediate threat but does not eliminate risk, especially in environments with heavy Btrfs usage.
Mitigation Recommendations
European organizations should prioritize updating Linux kernels to versions that include the patch fixing CVE-2024-35798. Since the vulnerability is in the kernel's Btrfs code, kernel upgrades are the primary mitigation. Organizations should: 1) Identify all systems using Btrfs filesystems and verify kernel versions against the fixed commit. 2) Test and deploy kernel updates in a controlled manner to avoid service disruption. 3) Implement monitoring for Btrfs filesystem errors and tree-checker warnings to detect early signs of corruption. 4) Regularly back up critical data stored on Btrfs volumes to enable recovery from corruption. 5) For high concurrency workloads, consider temporarily reducing parallel access to Btrfs volumes until patches are applied. 6) Engage with Linux distribution vendors for timely security updates and advisories. 7) Review and harden system configurations to limit unnecessary multi-threaded filesystem access where feasible. These steps go beyond generic advice by focusing on filesystem-specific monitoring and workload adjustments.
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-05-17T12:19:12.341Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d982ac4522896dcbe34dc
Added to database: 5/21/2025, 9:08:58 AM
Last enriched: 6/29/2025, 3:57:16 PM
Last updated: 8/1/2025, 9:23:57 AM
Views: 11
Related Threats
CVE-2025-41242: Vulnerability in VMware Spring Framework
MediumCVE-2025-47206: CWE-787 in QNAP Systems Inc. File Station 5
HighCVE-2025-5296: CWE-59 Improper Link Resolution Before File Access ('Link Following') in Schneider Electric SESU
HighCVE-2025-6625: CWE-20 Improper Input Validation in Schneider Electric Modicon M340
HighCVE-2025-57703: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in Delta Electronics DIAEnergie
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.