CVE-2024-49868: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: <TASK> commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.
AI Analysis
Technical Summary
CVE-2024-49868 is a vulnerability identified in the Linux kernel's Btrfs filesystem implementation. The flaw arises from a NULL pointer dereference triggered during error handling in the transaction management code of Btrfs, specifically when starting a new transaction fails. The root cause is a race condition between the error cleanup path and concurrent subvolume tree updates that create a relocation root (reloc_root). When allocation fails in start_transaction(), the error path calls unset_reloc_control(), setting fs_info->balance_ctl to NULL. However, if a subvolume tree update occurs in the small window between set_reloc_control() and unset_reloc_control(), a reloc_root can be created. Subsequently, during the cleanup in btrfs_commit_transaction(), the function btrfs_update_reloc_root() attempts to access fs_info->reloc_ctl without verifying if it is NULL, leading to a NULL pointer dereference and a kernel crash (general protection fault). This vulnerability can cause denial of service (system crash) on affected Linux systems using Btrfs. The fix involves adding a NULL check on fs_info->reloc_ctl in btrfs_update_reloc_root() to prevent dereferencing a NULL pointer. The vulnerability was reported by Syzbot and affects multiple Linux kernel versions identified by the same commit hash. No known exploits are currently reported in the wild. The issue is technical and specific to the Btrfs filesystem's transaction and relocation handling code paths, which are critical for filesystem integrity and stability.
Potential Impact
For European organizations, this vulnerability poses a risk primarily as a denial-of-service (DoS) vector on Linux systems utilizing the Btrfs filesystem. Given that Btrfs is increasingly used in enterprise environments, cloud infrastructure, and data centers for its advanced features like snapshots and volume management, exploitation could lead to unexpected system crashes, service interruptions, and potential data unavailability. This can affect critical services, especially those relying on Linux servers for storage and file management. While the vulnerability does not directly lead to privilege escalation or data corruption, the resulting kernel panic and system crash can disrupt business operations, cause downtime, and impact service-level agreements. Organizations with automated or high-volume transaction workloads on Btrfs may be more susceptible to triggering this bug. Additionally, recovery from crashes may require manual intervention or system reboots, increasing operational overhead. The lack of known exploits reduces immediate risk, but the presence of a kernel-level DoS vulnerability necessitates prompt patching to maintain system reliability and availability.
Mitigation Recommendations
To mitigate this vulnerability, European organizations should: 1) Apply the official Linux kernel patches that include the NULL pointer check fix in btrfs_update_reloc_root() as soon as they become available from trusted Linux distribution vendors or upstream sources. 2) Monitor kernel updates and prioritize updates for systems running Btrfs, especially those handling critical workloads or high transaction volumes. 3) Implement robust system monitoring to detect kernel crashes or Oops messages related to Btrfs, enabling rapid incident response. 4) Where possible, consider temporarily limiting or scheduling Btrfs balance and relocation operations during maintenance windows to reduce exposure until patches are applied. 5) Conduct thorough testing of kernel updates in staging environments to ensure stability before production deployment. 6) Maintain regular backups and disaster recovery plans to mitigate potential data availability impacts from unexpected crashes. 7) Educate system administrators about the vulnerability and encourage vigilance for unusual system behavior or crashes related to Btrfs operations.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Poland, Italy, Spain
CVE-2024-49868: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: <TASK> commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.
AI-Powered Analysis
Technical Analysis
CVE-2024-49868 is a vulnerability identified in the Linux kernel's Btrfs filesystem implementation. The flaw arises from a NULL pointer dereference triggered during error handling in the transaction management code of Btrfs, specifically when starting a new transaction fails. The root cause is a race condition between the error cleanup path and concurrent subvolume tree updates that create a relocation root (reloc_root). When allocation fails in start_transaction(), the error path calls unset_reloc_control(), setting fs_info->balance_ctl to NULL. However, if a subvolume tree update occurs in the small window between set_reloc_control() and unset_reloc_control(), a reloc_root can be created. Subsequently, during the cleanup in btrfs_commit_transaction(), the function btrfs_update_reloc_root() attempts to access fs_info->reloc_ctl without verifying if it is NULL, leading to a NULL pointer dereference and a kernel crash (general protection fault). This vulnerability can cause denial of service (system crash) on affected Linux systems using Btrfs. The fix involves adding a NULL check on fs_info->reloc_ctl in btrfs_update_reloc_root() to prevent dereferencing a NULL pointer. The vulnerability was reported by Syzbot and affects multiple Linux kernel versions identified by the same commit hash. No known exploits are currently reported in the wild. The issue is technical and specific to the Btrfs filesystem's transaction and relocation handling code paths, which are critical for filesystem integrity and stability.
Potential Impact
For European organizations, this vulnerability poses a risk primarily as a denial-of-service (DoS) vector on Linux systems utilizing the Btrfs filesystem. Given that Btrfs is increasingly used in enterprise environments, cloud infrastructure, and data centers for its advanced features like snapshots and volume management, exploitation could lead to unexpected system crashes, service interruptions, and potential data unavailability. This can affect critical services, especially those relying on Linux servers for storage and file management. While the vulnerability does not directly lead to privilege escalation or data corruption, the resulting kernel panic and system crash can disrupt business operations, cause downtime, and impact service-level agreements. Organizations with automated or high-volume transaction workloads on Btrfs may be more susceptible to triggering this bug. Additionally, recovery from crashes may require manual intervention or system reboots, increasing operational overhead. The lack of known exploits reduces immediate risk, but the presence of a kernel-level DoS vulnerability necessitates prompt patching to maintain system reliability and availability.
Mitigation Recommendations
To mitigate this vulnerability, European organizations should: 1) Apply the official Linux kernel patches that include the NULL pointer check fix in btrfs_update_reloc_root() as soon as they become available from trusted Linux distribution vendors or upstream sources. 2) Monitor kernel updates and prioritize updates for systems running Btrfs, especially those handling critical workloads or high transaction volumes. 3) Implement robust system monitoring to detect kernel crashes or Oops messages related to Btrfs, enabling rapid incident response. 4) Where possible, consider temporarily limiting or scheduling Btrfs balance and relocation operations during maintenance windows to reduce exposure until patches are applied. 5) Conduct thorough testing of kernel updates in staging environments to ensure stability before production deployment. 6) Maintain regular backups and disaster recovery plans to mitigate potential data availability impacts from unexpected crashes. 7) Educate system administrators about the vulnerability and encourage vigilance for unusual system behavior or crashes related to Btrfs operations.
Affected Countries
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-10-21T12:17:06.019Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9825c4522896dcbe0816
Added to database: 5/21/2025, 9:08:53 AM
Last enriched: 6/28/2025, 8:56:15 PM
Last updated: 7/30/2025, 5:58:44 PM
Views: 12
Related Threats
CVE-2025-8885: CWE-770 Allocation of Resources Without Limits or Throttling in Legion of the Bouncy Castle Inc. Bouncy Castle for Java
MediumCVE-2025-26398: CWE-798 Use of Hard-coded Credentials in SolarWinds Database Performance Analyzer
MediumCVE-2025-41686: CWE-306 Missing Authentication for Critical Function in Phoenix Contact DaUM
HighCVE-2025-8874: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in litonice13 Master Addons – Elementor Addons with White Label, Free Widgets, Hover Effects, Conditions, & Animations
MediumCVE-2025-8767: CWE-1236 Improper Neutralization of Formula Elements in a CSV File in anwppro AnWP Football Leagues
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.