CVE-2025-38260
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-07-09

Last updated on: 2025-12-18

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: btrfs: handle csum tree error with rescue=ibadroots correctly [BUG] There is syzbot based reproducer that can crash the kernel, with the following call trace: (With some debug output added) DEBUG: rescue=ibadroots parsed BTRFS: device fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) scanned by repro (1010) BTRFS info (device loop0): first mount of filesystem 14d642db-7b15-43e4-81e6-4b8fac6a25f8 BTRFS info (device loop0): using blake2b (blake2b-256-generic) checksum algorithm BTRFS info (device loop0): using free-space-tree BTRFS warning (device loop0): checksum verify failed on logical 5312512 mirror 1 wanted 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 found 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 level 0 DEBUG: read tree root path failed for tree csum, ret=-5 BTRFS warning (device loop0): checksum verify failed on logical 5328896 mirror 1 wanted 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a found 0x51be4e8b303da58e634022a315b70e3a93592dac3f30dd510c7517454de8567a level 0 BTRFS warning (device loop0): checksum verify failed on logical 5292032 mirror 1 wanted 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4 found 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e level 0 process 'repro' launched './file2' with NULL argv: empty string added DEBUG: no csum root, idatacsums=0 ibadroots=134217728 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f] CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G OE 6.15.0-custom+ #249 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs] Call Trace: <TASK> btrfs_lookup_bio_sums+0x47a/0xdf0 [btrfs] btrfs_submit_bbio+0x43e/0x1a80 [btrfs] submit_one_bio+0xde/0x160 [btrfs] btrfs_readahead+0x498/0x6a0 [btrfs] read_pages+0x1c3/0xb20 page_cache_ra_order+0x4b5/0xc20 filemap_get_pages+0x2d3/0x19e0 filemap_read+0x314/0xde0 __kernel_read+0x35b/0x900 bprm_execve+0x62e/0x1140 do_execveat_common.isra.0+0x3fc/0x520 __x64_sys_execveat+0xdc/0x130 do_syscall_64+0x54/0x1d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]--- [CAUSE] Firstly the fs has a corrupted csum tree root, thus to mount the fs we have to go "ro,rescue=ibadroots" mount option. Normally with that mount option, a bad csum tree root should set BTRFS_FS_STATE_NO_DATA_CSUMS flag, so that any future data read will ignore csum search. But in this particular case, we have the following call trace that caused NULL csum root, but not setting BTRFS_FS_STATE_NO_DATA_CSUMS: load_global_roots_objectid(): ret = btrfs_search_slot(); /* Succeeded */ btrfs_item_key_to_cpu() found = true; /* We found the root item for csum tree. */ root = read_tree_root_path(); if (IS_ERR(root)) { if (!btrfs_test_opt(fs_info, IGNOREBADROOTS)) /* * Since we have rescue=ibadroots mount option, * @ret is still 0. */ break; if (!found || ret) { /* @found is true, @ret is 0, error handling for csum * tree is skipped. */ } This means we completely skipped to set BTRFS_FS_STATE_NO_DATA_CSUMS if the csum tree is corrupted, which results unexpected later csum lookup. [FIX] If read_tree_root_path() failed, always populate @ret to the error number. As at the end of the function, we need @ret to determine if we need to do the extra error handling for csum tree.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-09
Last Modified
2025-12-18
Generated
2026-05-07
AI Q&A
2025-07-09
EPSS Evaluated
2026-05-05
NVD
CVE-2025-38260
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.16
linux linux_kernel From 6.7 (inc) to 6.12.36 (inc)
debian debian_linux 11.0
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is in the Linux kernel's Btrfs filesystem. It occurs when the checksum (csum) tree root is corrupted and the filesystem is mounted with the 'rescue=ibadroots' option. Normally, a corrupted csum tree root should trigger a flag (BTRFS_FS_STATE_NO_DATA_CSUMS) to ignore checksum searches on future data reads. However, due to improper error handling, this flag is not set when the csum tree root is corrupted, leading to unexpected checksum lookups. This can cause a kernel crash due to a NULL pointer dereference during checksum verification.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to crash (kernel panic) when accessing a Btrfs filesystem with a corrupted checksum tree root under certain mount options. This can lead to system instability, denial of service, and potential data access interruptions on affected systems.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing kernel logs for specific BTRFS checksum errors and kernel crashes related to the csum tree. Look for messages such as 'BTRFS warning: checksum verify failed' and kernel oops traces involving 'btrfs_lookup_csum'. You can check kernel logs using commands like 'dmesg | grep BTRFS' or 'journalctl -k | grep BTRFS'. Additionally, mounting the affected BTRFS filesystem with the 'rescue=ibadroots' option may reveal errors related to corrupted checksum tree roots.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version that includes the fix for this vulnerability. The fix ensures proper handling of corrupted checksum tree roots by correctly setting the BTRFS_FS_STATE_NO_DATA_CSUMS flag to avoid kernel crashes. Until the update is applied, avoid mounting affected BTRFS filesystems without the 'rescue=ibadroots' mount option, which helps to handle corrupted checksum roots more safely.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart