CVE-2026-23214
Received Received - Intake
Improper Transaction Handling in Btrfs Causes Data Corruption Risk

Publication date: 2026-02-18

Last updated on: 2026-03-18

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: btrfs: reject new transactions if the fs is fully read-only [BUG] There is a bug report where a heavily fuzzed fs is mounted with all rescue mount options, which leads to the following warnings during unmount: BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: <TASK> btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/super.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit.c:1112 __do_sys_exit_group kernel/exit.c:1123 [inline] __se_sys_exit_group kernel/exit.c:1121 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK> Since rescue mount options will mark the full fs read-only, there should be no new transaction triggered. But during unmount we will evict all inodes, which can trigger a new transaction, and triggers warnings on a heavily corrupted fs. [CAUSE] Btrfs allows new transaction even on a read-only fs, this is to allow log replay happen even on read-only mounts, just like what ext4/xfs do. However with rescue mount options, the fs is fully read-only and cannot be remounted read-write, thus in that case we should also reject any new transactions. [FIX] If we find the fs has rescue mount options, we should treat the fs as error, so that no new transaction can be started.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-18
Last Modified
2026-03-18
Generated
2026-05-07
AI Q&A
2026-02-18
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 8 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.13 (inc) to 6.18.10 (exc)
linux linux_kernel From 5.11 (inc) to 6.12.70 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's btrfs filesystem. It occurs because btrfs allows new transactions to be started even when the filesystem is mounted as read-only. This behavior is normally intended to allow log replay on read-only mounts. However, when the filesystem is mounted with rescue options, it is fully read-only and cannot be remounted as read-write. In this case, new transactions should be rejected but are not, which leads to warnings and errors during unmounting, especially on heavily corrupted filesystems.

The issue manifests as warnings like 'BTRFS: Transaction aborted (error -22)' during unmount, caused by attempts to start new transactions while evicting inodes on a fully read-only filesystem mounted with rescue options.

The fix involves detecting when the filesystem is mounted with rescue options and treating it as an error state that rejects any new transactions.


How can this vulnerability impact me? :

This vulnerability can cause filesystem errors and warnings during unmount operations on btrfs filesystems that are mounted with rescue options and are heavily corrupted. Specifically, it can lead to aborted transactions and potential instability or data integrity issues during the unmount process.

While it does not directly allow unauthorized access or data corruption by itself, the improper handling of transactions on a fully read-only filesystem could complicate recovery efforts or lead to unexpected behavior in system shutdown or filesystem maintenance.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


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

This vulnerability manifests as warnings during unmount of a heavily fuzzed btrfs filesystem mounted with rescue mount options. Specifically, you may observe kernel log messages such as "BTRFS: Transaction aborted (error -22)" along with stack traces related to btrfs transaction handling.

To detect this issue on your system, you can monitor the kernel logs for these specific warnings when unmounting btrfs filesystems.

Suggested commands to check for this vulnerability include:

  • Use dmesg or journalctl to review kernel logs for btrfs transaction abort warnings: `dmesg | grep -i btrfs` or `journalctl -k | grep -i btrfs`
  • Check mount options of btrfs filesystems to see if rescue mount options are used: `mount | grep btrfs`
  • Attempt to unmount btrfs filesystems and observe if warnings appear in kernel logs.

What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by rejecting new transactions on btrfs filesystems mounted with rescue mount options, treating the filesystem as fully read-only to prevent transaction creation.

Immediate mitigation steps include:

  • Avoid mounting btrfs filesystems with rescue mount options unless necessary.
  • Apply the updated Linux kernel patch that includes the fix for this issue to ensure that new transactions are rejected on fully read-only btrfs filesystems.
  • Monitor kernel logs for any warnings related to btrfs transactions and avoid unmounting corrupted or fuzzed btrfs filesystems without the fix.

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