CVE-2026-31666

What it actually does

CVE-2026-31666 is a Linux kernel Btrfs filesystem logic error in lookup_extent_data_ref(). A failed extent data reference lookup can incorrectly return success after moving to the next Btrfs leaf, causing callers to operate as if the expected extent tree item was found when it was not. In affected kernels, a local user or local workload that can exercise relevant Btrfs filesystem operations may trigger incorrect extent-tree handling, potentially leading to filesystem metadata corruption, kernel instability, denial of service, and, depending on reachable code paths and system configuration, broader compromise of confidentiality, integrity, or availability. The CVSS vector indicates local access with low privileges and no user interaction required.

Why it matters to the business

Systems using affected Linux kernels with Btrfs-backed filesystems may be exposed to data corruption, service disruption, or host instability if the vulnerable code path is triggered. The main operational risk is loss of trust in filesystem integrity, possible downtime for recovery or restoration, and potential impact to workloads whose data resides on Btrfs volumes. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no known public exploit maturity, and has a very low stable EPSS score, so urgency should be driven primarily by Btrfs usage, exposure to untrusted local users or workloads, and the criticality of affected hosts.

How an attack unfolds

An attacker first needs local code execution or the ability to run filesystem operations on a host using an affected Linux kernel with a Btrfs filesystem. The attacker then performs Btrfs operations that cause lookup_extent_data_ref() to search for an extent data reference near a leaf boundary. Due to the incorrect return-value handling, the lookup may report success after btrfs_next_leaf() even when the first key in the next leaf does not match the requested object ID or item type. Downstream code may then act on the wrong extent tree state, creating conditions for extent tree corruption. In practical terms, exploitation would likely appear as local abuse leading to filesystem inconsistency, kernel errors, crashes, or data integrity issues rather than a straightforward remote intrusion path. No named threat actors or active exploitation campaigns are currently associated with this vulnerability in the provided intelligence.

How to fix it

Update the Linux kernel to a vendor-supported release that includes the upstream Btrfs fix for incorrect return handling in lookup_extent_data_ref(). Because no exact fixed package versions were provided, use the security advisory from the relevant Linux distribution or kernel supplier to identify the corrected kernel build. Prioritize systems that mount Btrfs filesystems, especially multi-user hosts, virtualization or container hosts, build systems, storage servers, and endpoints where untrusted users or workloads can perform local filesystem operations. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads on Btrfs-backed storage, moving high-risk workloads to patched hosts, maintaining verified backups, and monitoring Btrfs health. Avoid treating filesystem repair as a substitute for patching; repair may address corruption after the fact but does not remove the vulnerable kernel behavior.

How to confirm the fix worked

Confirm exposure by checking both kernel version and Btrfs usage. Inventory systems running Linux kernels that predate the vendor fix, then identify mounted Btrfs filesystems using commands such as findmnt -t btrfs, mount | grep btrfs, or lsblk -f. Validate remediation by confirming the running kernel package is at or above the vendor-fixed version and that the host has rebooted into the fixed kernel, not merely installed it. Review distribution advisories, kernel changelogs, or package metadata for the Btrfs fix referencing lookup_extent_data_ref(), btrfs_next_leaf(), or returning -ENOENT when the key does not match. After patching, run normal filesystem health checks appropriate for Btrfs, review dmesg and journal logs for new Btrfs errors, and ensure no affected old kernels remain bootable as the default.

Typical attack path

1. Gain local access to a Linux system, container host, development server, or multi-user system running an affected kernel.
2. Confirm or infer that one or more writable filesystems are Btrfs.
3. Perform crafted or high-volume filesystem operations intended to exercise Btrfs extent data reference lookup behavior, especially around extent-tree leaf transitions.
4. Trigger the vulnerable lookup path so a missing extent data reference is incorrectly treated as found.
5. Cause incorrect extent-tree handling, potentially resulting in filesystem metadata corruption, kernel warnings, crashes, remounts, or denial of service.
6. Leverage resulting instability or corruption to disrupt services, damage data integrity, or create recovery burden.

How to detect it

There are no specific public exploit indicators provided for this vulnerability, and exploitation is local rather than network-based. To assess whether it may already have been triggered, review host telemetry for Btrfs metadata corruption, kernel warnings, BUG/OOPS messages, unexpected remounts, filesystem check failures, and crashes on systems running affected kernels with Btrfs. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, systemd journal logs, EDR process history for unusual local filesystem stress tools, and Btrfs maintenance logs. Investigate timestamps where Btrfs errors coincide with suspicious local user activity, newly created high-volume file operations, fuzzing tools, stress-test utilities, or untrusted workload execution. Because the likely artifacts are filesystem and kernel symptoms rather than unique malware indicators, absence of these logs does not prove non-exploitation, and presence of them does not by itself prove malicious activity.

• BTRFS error
• BTRFS warning
• BTRFS critical
• BTRFS info
• lookup_extent_data_ref
• btrfs_next_leaf
• extent tree corruption
• extent tree
• parent transid verify failed
• bad tree block
• corrupt leaf
• bad key order
• invalid extent item
• failed to run delayed ref
• unable to find ref byte nr
• read error corrected
• open_ctree failed
• forced readonly
• remounting filesystem read-only
• kernel BUG at fs/btrfs
• WARNING: CPU:
• Oops:
• btrfs check
• btrfs scrub

What your security team should do

• Inventory Linux hosts using Btrfs and rank them by criticality, local-user exposure, and workload trust level.
• Patch and reboot Btrfs-using systems to a vendor kernel containing the fix; prioritize shared, multi-tenant, and storage-critical systems.
• For systems that cannot be patched immediately, restrict local access and avoid running untrusted workloads on Btrfs-backed filesystems.
• Increase monitoring for Btrfs filesystem errors, kernel warnings, unexpected read-only remounts, crashes, and service disruptions.
• Verify backup coverage and restore procedures for important data stored on Btrfs volumes before and after remediation.
• Check that patched systems are actually running the fixed kernel after reboot and that older vulnerable kernels are not selected by the bootloader.
• Track vendor advisories for exact fixed package versions because no fixed versions were provided in the input.
• Treat unexplained Btrfs metadata corruption on affected kernels as potentially security-relevant and preserve logs for investigation.