CVE-2026-46251

What it actually does

This is a Linux kernel Btrfs memory-corruption flaw in transaction commit handling when the Btrfs EXTENT_TREE_V2 incompatibility feature is enabled. The block group tree can be added to a commit list even though it is already linked through normal dirty-root tracking, corrupting the kernel linked-list pointers in the Btrfs root dirty_list. On later transaction commits or block-group creation, the corrupted lists can cause kernel warnings, transaction aborts, filesystem errors, denial of service, and potentially broader kernel memory corruption. Because the flaw is in kernel-space filesystem code and the CVSS vector is local with no privileges required, a local user or workload with access to perform filesystem activity on an affected Btrfs filesystem may be able to trigger high-impact confidentiality, integrity, and availability consequences if exploitation is weaponized.

Why it matters to the business

Systems using affected Linux kernels with Btrfs filesystems, especially filesystems using the newer EXTENT_TREE_V2 feature, may experience filesystem transaction aborts, kernel instability, forced read-only remounts, crashes, data-integrity risk, or service outages. The vulnerability is not listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, so broad internet-scale exploitation is not currently indicated; however, kernel memory-corruption issues still warrant timely patching on multi-user servers, container hosts, developer workstations, storage nodes, and any environment where untrusted local code can write to Btrfs-backed storage.

How an attack unfolds

An attacker first needs local code execution or the ability to run an untrusted workload on a host using an affected Linux kernel with a writable Btrfs filesystem that has EXTENT_TREE_V2 enabled. The attacker performs filesystem operations that cause Btrfs allocations and dirty a block group, then forces or waits for a transaction commit through normal filesystem synchronization behavior. During commit handling, the vulnerable kernel path incorrectly links the block group root into a commit list even though it may already be linked on another dirty-tracking list. This corrupts linked-list metadata in kernel memory. Subsequent commits or block-group operations can trigger list validation failures, Btrfs root lookup failures, transaction aborts, and possibly a kernel crash or filesystem disruption. No public exploit is indicated in the supplied intelligence, but because the primitive is kernel memory corruption, defenders should treat exposed multi-user systems as higher risk than the low EPSS alone suggests.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the Btrfs fix for the block_group_tree dirty_list corruption issue. No exact fixed package versions were provided in the input, so use vendor advisories and kernel changelogs to confirm inclusion of the patch titled similar to "btrfs: fix block_group_tree dirty_list corruption." After updating, reboot into the fixed kernel and ensure the old vulnerable kernel is not selected by default. Where immediate patching is not possible, reduce exposure by avoiding Btrfs filesystems with EXTENT_TREE_V2 on affected kernels, limiting local shell access, preventing untrusted containers or build jobs from writing to Btrfs-backed storage, restricting user-mountable filesystems, and maintaining current backups before performing heavy Btrfs maintenance or migration operations.

How to confirm the fix worked

Confirm the running kernel version with uname -r and verify the installed kernel package includes the vendor fix for this Btrfs patch, not merely that the package is downloaded. Reboot and confirm the active kernel is the fixed kernel. Inventory Btrfs usage with commands such as findmnt -t btrfs and review filesystem feature flags with appropriate Btrfs tooling, such as btrfs inspect-internal dump-super, looking for EXTENT_TREE_V2 where supported. Review kernel logs with dmesg or journalctl -k for Btrfs list corruption, transaction abort, or root lookup errors before and after remediation. On patched test systems, normal Btrfs write, allocation, and sync activity should not produce list_del corruption warnings or Btrfs transaction aborts associated with switch_commit_roots or btrfs_commit_transaction.

Typical attack path

1. Gain the ability to run local code or an untrusted workload on a Linux system using an affected kernel.
2. Identify or access a writable Btrfs filesystem, particularly one created or mounted with the EXTENT_TREE_V2 incompatibility feature.
3. Perform filesystem writes, allocations, or metadata-changing operations that dirty Btrfs block group state.
4. Trigger or wait for transaction commit activity, such as sync, fsync, periodic writeback, or normal Btrfs transaction completion.
5. Cause corruption of the Btrfs block group root dirty_list / commit-list linkage inside kernel memory.
6. Leverage the resulting condition to cause Btrfs transaction aborts, filesystem unavailability, kernel warnings/oopses, crashes, or potentially further kernel compromise if a reliable exploit is developed.

How to detect it

To determine whether the issue was already triggered, review kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, and centralized log collectors for Btrfs warnings, linked-list corruption reports, transaction aborts, and call traces around transaction commits. Focus on events from hosts using Btrfs, especially where EXTENT_TREE_V2 is enabled. Look for kernel traces involving __list_del_entry_valid_or_report, switch_commit_roots, btrfs_commit_transaction, ksys_sync, and BTRFS transaction abort messages. Correlate timestamps with local user sessions, container jobs, build workloads, storage stress tests, backup jobs, or any process issuing heavy writes or sync operations. Evidence of exploitation will likely look like kernel instability or filesystem failure rather than a clean network IOC. Preserve kernel logs, crash dumps, pstore records, vmcore files, and Btrfs diagnostic output if suspicious crashes or transaction aborts occurred.

• list_del corruption. next->prev should be
• __list_del_entry_valid_or_report
• switch_commit_roots
• btrfs_commit_transaction
• BTRFS critical
• unable to find root key (1 0 0) in tree 1
• BTRFS: Transaction aborted (error -117)
• fs/btrfs/root-tree.c:153
• lib/list_debug.c:65
• ksys_sync
• [btrfs]
• EXTENT_TREE_V2

What your security team should do

• Prioritize patching Linux systems that use Btrfs for production storage, shared compute, container hosting, CI/CD workloads, multi-user access, or untrusted local workloads.
• Identify all Btrfs mounts and determine whether EXTENT_TREE_V2 is enabled; treat those systems as the primary exposure set.
• Monitor kernel logs centrally for Btrfs transaction aborts, list corruption warnings, and call traces involving switch_commit_roots or btrfs_commit_transaction.
• Where patching must be delayed, restrict local access and untrusted workload execution on systems with writable Btrfs filesystems.
• Ensure recent, restorable backups exist for affected Btrfs volumes before heavy write workloads, maintenance, or kernel changes.
• Track distribution advisories for exact fixed kernel versions because no fixed versions were supplied in the vulnerability metadata.
• Do not rely solely on EPSS or KEV status for prioritization; local kernel memory-corruption flaws can be serious on systems where untrusted code can run.