CVE-2026-43308

What it actually does

This is a local denial-of-service flaw in the Linux kernel Btrfs filesystem code. A vulnerable kernel can call BUG() when run_one_delayed_ref() encounters an unexpected delayed reference type, causing an intentional kernel crash or panic instead of returning an error. The impact is availability loss only: it does not provide confidentiality or integrity impact and does not directly enable privilege escalation or remote code execution. Exploitation requires local access with low privileges and a workload or filesystem interaction path capable of reaching the affected Btrfs delayed-reference handling code.

Why it matters to the business

Systems using Btrfs on affected Linux kernels may be crashed by a local user or workload, causing service interruption, failed jobs, container or VM disruption, and possible data recovery procedures after reboot. The CVSS availability impact is high, but current exploitation likelihood appears low: EPSS is 0.00107, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity is reported. Organizations with multi-user Linux systems, shared build hosts, container platforms, storage nodes, or appliances using Btrfs should still prioritize remediation because a local crash can affect many dependent services.

How an attack unfolds

An attacker first obtains local access to a vulnerable Linux system, typically as an unprivileged authenticated user or as code running inside a local workload. They then perform filesystem activity against a mounted Btrfs filesystem that causes delayed reference processing to encounter an unexpected reference type. On vulnerable kernels, the Btrfs code path responds with BUG() rather than safely returning an error, which triggers a kernel panic or fatal oops. The host may immediately crash, reboot, or become unavailable until manually recovered, interrupting all workloads on that system. There is no indication from the provided information that the flaw enables code execution, data theft, or privilege escalation.

How to fix it

Upgrade to a kernel version from the relevant Linux distribution or vendor that includes the Btrfs fix changing this BUG() condition into safe error handling and logging. No exact fixed package versions were provided, so use vendor advisories, kernel changelogs, and distribution security trackers to identify the first patched kernel for each supported release. Prioritize hosts that use Btrfs for root filesystems, data volumes, container storage, snapshots, or appliance storage. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads on Btrfs-backed systems, disabling or avoiding Btrfs where operationally feasible, moving high-risk workloads to non-Btrfs storage, and ensuring automatic reboot and service recovery controls are in place. Apply normal kernel patching precautions, including maintenance windows, backup validation, and rollback planning.

How to confirm the fix worked

Confirm whether systems are exposed by checking the running kernel version and whether Btrfs is loaded or mounted. Use commands such as uname -a, package manager queries, lsmod | grep btrfs, findmnt -t btrfs, and mount | grep btrfs. Validate remediation by confirming the installed and running kernel package is vendor-patched for this issue and that systems have actually rebooted into the fixed kernel. Review vendor kernel changelogs or source patches for the Btrfs change that removes the BUG() behavior in run_one_delayed_ref(). After patching, verify stability under representative Btrfs workloads and monitor kernel logs for Btrfs delayed-reference errors rather than kernel panics.

Typical attack path

1. Identify a Linux host running an affected kernel with Btrfs enabled or mounted.
2. Obtain local low-privileged access or execute code through an existing local workload context.
3. Trigger Btrfs filesystem operations that reach delayed reference processing in run_one_delayed_ref().
4. Cause the vulnerable kernel to hit the unexpected delayed reference type condition.
5. The kernel executes BUG(), resulting in a panic, fatal oops, reboot, or host-level denial of service.
6. Services and workloads on the affected system remain unavailable until the host is recovered and the kernel is patched or mitigated.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal logs, syslog, crash dumps, pstore records, hypervisor reset events, and uptime/reboot history for unexplained kernel panics or fatal oops events involving Btrfs. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, /sys/fs/pstore, kdump/vmcore repositories, and centralized log/SIEM records. Focus on events containing Btrfs delayed-reference processing, run_one_delayed_ref(), kernel BUG, Oops, panic, or stack traces in fs/btrfs/extent-tree.c. Correlate crash timestamps with local user sessions, scheduled jobs, container activity, filesystem-heavy operations, package builds, snapshot/subvolume operations, and mount/unmount activity. Because exploitation is local and may look like an ordinary kernel crash, absence of a unique exploit string does not prove non-exploitation; repeated Btrfs-related panics on unpatched kernels should be treated as suspicious until explained.

• run_one_delayed_ref
• fs/btrfs/extent-tree.c
• BTRFS
• btrfs
• kernel BUG
• BUG: kernel
• Oops:
• Kernel panic
• panic: Fatal exception
• delayed ref
• delayed reference
• unexpected delayed ref type
• /var/crash
• /sys/fs/pstore
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems using Btrfs and rank them by business criticality, multi-user exposure, and workload density.
• Patch or upgrade affected kernels through vendor-supported channels, prioritizing Btrfs-backed production, shared, and container-host systems.
• Confirm patched systems have rebooted into the fixed kernel; installed-but-not-running kernel updates do not remediate kernel vulnerabilities.
• Restrict local access and untrusted workload execution on vulnerable Btrfs-backed hosts until patching is complete.
• Ensure crash dump, pstore, journald, and centralized syslog collection are enabled so kernel panics and Btrfs errors are retained after reboot.
• Create detections for kernel BUG/oops or panic messages referencing Btrfs delayed references and run_one_delayed_ref().
• Review recent unexplained reboots or host crashes on Btrfs systems for signs consistent with this flaw.
• Because EPSS is low, there is no KEV listing, and no public exploit maturity is reported, handle this as an important availability hardening issue rather than an emergency internet-facing compromise scenario.