CVE-2026-45974
Medium · 5.5CVSS
5.5
EPSS
0.1%
Published
May 27, 2026
CISA due date
—
Cloudanix analysis
A flaw in some Linux systems can let a local user crash machines that use a specific filesystem feature, interrupting services until the system is recovered and patched.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
This is a local denial-of-service flaw in the Linux kernel Btrfs filesystem quota-enable path. When enabling Btrfs quotas, the kernel may call btrfs_search_slot_for_read() and receive a return value indicating that no suitable key was found and the traversal has reached the end of the tree. The vulnerable code continued to use the invalid path instead of stopping, which can lead to invalid leaf access in kernel space. The practical impact is a kernel crash, oops, or panic affecting system availability. The flaw does not directly provide confidentiality or integrity impact and does not indicate remote code execution.
Why it matters to the business
An attacker with local access and sufficient ability to trigger Btrfs quota operations could crash an affected Linux system, causing service interruption, workload disruption, failed jobs, or node instability. Systems using Btrfs are most relevant, especially where quota management is enabled or exposed through administrative tooling, containers, automation, or delegated storage operations. The issue is not listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, so broad exploitation is not currently expected; however, availability-sensitive Linux systems should still be patched during the next appropriate maintenance window.
How an attack unfolds
An attacker first needs local access to a vulnerable Linux system using Btrfs. They then need a way to trigger Btrfs quota enablement against a crafted or edge-case filesystem state where the quota-enable logic searches for a reference key that is not present. In vulnerable kernels, when the search reaches the end of the tree, the code fails to stop processing and proceeds with an invalid path. This can cause an invalid leaf access inside the kernel Btrfs code path, leading to a kernel oops or panic. Successful exploitation results in denial of service rather than data theft or code execution. There are no named threat actors or known active exploitation campaigns associated with this issue based on the provided intelligence.
How to fix it
Upgrade to a Linux kernel version that includes the upstream Btrfs fix for invalid leaf access in btrfs_quota_enable(). Because no exact fixed package versions were provided, use the relevant Linux distribution vendor advisory and install the latest kernel security update for the affected release stream. Reboot systems after installing the fixed kernel, since the vulnerable code remains active until the new kernel is running. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting who can perform Btrfs administration, avoiding delegated quota-management operations on Btrfs filesystems, and monitoring for unexpected Btrfs quota enable attempts. If Btrfs is not required, consider disabling or avoiding its use on high-availability systems until patched.
How to confirm the fix worked
Confirm the running kernel has been updated to a vendor build that includes the Btrfs quota-enable fix, not merely that a package has been installed. Validate with commands such as uname -r and the distribution package manager to ensure the active kernel matches the fixed advisory version. Check whether Btrfs is in use by reviewing mounted filesystems with findmnt -t btrfs or mount output. If Btrfs is present, confirm only authorized administrators can run Btrfs quota operations. Review recent kernel logs for Btrfs crashes or oops events around quota enablement. After patching and rebooting, controlled validation can include enabling quotas on a non-production test Btrfs filesystem and confirming no kernel oops, panic, or invalid leaf access occurs.
Typical attack path
- Gain local access to a Linux host running an affected kernel with Btrfs support.
- Identify or create a Btrfs filesystem state where enabling quotas causes the quota code to search for a missing reference key.
- Trigger Btrfs quota enablement, commonly through administrative or storage-management interfaces that invoke Btrfs quota operations.
- Cause the vulnerable kernel path to continue after btrfs_search_slot_for_read() indicates the tree search is no longer valid.
- Trigger invalid Btrfs leaf access, resulting in a kernel oops, panic, or system crash.
- Use the crash to disrupt workloads or repeatedly deny service if access remains available.
How to detect it
To determine whether this was already exploited or accidentally triggered, review kernel and system logs for Btrfs quota activity followed by a kernel oops, BUG, panic, general protection fault, or invalid memory access. Useful log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore metadata, auditd logs, sudo logs, shell history, and endpoint telemetry for executions of btrfs quota enable. Correlate timestamps of btrfs command execution, quota-management automation, or administrative sessions with system crashes or reboots. Look specifically for stack traces containing btrfs_quota_enable, btrfs_search_slot_for_read, Btrfs qgroup/quota code, or invalid leaf/path access. Since there are no known public exploit artifacts or network indicators for this local kernel DoS, detection should focus on host telemetry, kernel crash evidence, and suspicious or unauthorized Btrfs quota operations.
- btrfs quota enable
- btrfs_quota_enable
- btrfs_search_slot_for_read
- BTRFS
- BTRFS error
- BTRFS critical
- kernel BUG
- Oops:
- Kernel panic
- general protection fault
- invalid leaf
- invalid path
- qgroup
- quota enable
- /var/log/kern.log
- /var/log/messages
- /var/log/syslog
- /var/crash/
- /var/lib/systemd/coredump/
- vmcore
What your security team should do
- Prioritize patching Linux systems that use Btrfs, especially production hosts, storage nodes, virtualization hosts, container platforms, and availability-sensitive workloads.
- Use vendor kernel advisories to identify the first fixed package for each Linux distribution and ensure systems are rebooted into the fixed kernel.
- Inventory Btrfs usage across Linux fleets with mount, findmnt, configuration-management data, or endpoint telemetry.
- Restrict local access and Btrfs administrative privileges to trusted administrators until patched.
- Monitor kernel logs for Btrfs quota-enable activity followed by oops, panic, BUG, or invalid leaf access messages.
- Treat unexplained crashes on Btrfs systems as potentially security-relevant until kernel logs and administrative activity are reviewed.
- Because the issue is not in KEV, has low EPSS, and has no known exploit maturity, schedule remediation based on exposure and availability criticality rather than emergency internet-facing RCE procedures.
The record
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid path.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|