CVE-2026-43359

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel Btrfs filesystem. A low-privileged local user who owns Btrfs subvolumes can repeatedly invoke the set received subvolume ioctl with the same received UUID across many subvolumes, causing an item overflow during metadata updates. In vulnerable kernels, the overflow path occurs after a transaction has already started and metadata has been modified, which forces a Btrfs transaction abort and remounts the affected filesystem read-only. Confidentiality and integrity are not directly impacted, but availability of any workload depending on writes to that filesystem can be disrupted.

Why it matters to the business

An authenticated local user, compromised account, or untrusted workload on a system using Btrfs can make a filesystem stop accepting writes, causing application failures, failed deployments, interrupted backups, logging outages, or service downtime. The issue is not listed in CISA KEV, has no known ransomware association, and currently has very low EPSS, so broad internet-scale exploitation is unlikely; however, it is operationally important on multi-user Linux systems, shared compute platforms, developer workstations, container hosts, CI runners, and servers that expose Btrfs subvolume ownership to non-administrators.

How an attack unfolds

An attacker first obtains low-privileged local access to a Linux system that uses Btrfs. They identify or create Btrfs subvolumes they own. The attacker then repeatedly calls the Btrfs set received subvolume ioctl using the same received UUID value for many owned subvolumes. The vulnerable kernel performs metadata updates before detecting that adding the BTRFS_UUID_KEY_RECEIVED_SUBVOL item would overflow. When the overflow is encountered, the kernel aborts the active Btrfs transaction to preserve filesystem consistency. The abort causes the filesystem to transition into read-only mode, preventing legitimate processes from writing until administrative recovery is performed, typically requiring investigation, remounting, and in some cases reboot or filesystem repair procedures.

How to fix it

Upgrade to a Linux kernel build from the operating system or distribution vendor that includes the Btrfs fix for this issue. The corrected behavior performs an early overflow check before starting the transaction, preventing the forced transaction abort. No exact upstream or per-distribution fixed version was provided in the input, so track the relevant vendor kernel advisory for the deployed distribution and kernel stream. Where immediate patching is not possible, reduce exposure by avoiding Btrfs for systems with untrusted local users, restricting shell or job execution access for untrusted users, preventing untrusted users from owning or creating Btrfs subvolumes, isolating untrusted workloads on non-Btrfs filesystems, and using sandboxing controls such as seccomp, container runtime policies, or LSM profiles to restrict filesystem-management ioctls where practical. Ensure backups and recovery procedures exist for systems whose availability depends on writable Btrfs volumes.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release that contains the Btrfs transaction-abort fix. Verify the system is actually booted into the patched kernel, not only that a patched package is installed. Inventory mounted filesystems with findmnt, mount, or /proc/mounts and identify systems using Btrfs. On patched test systems, attempts to exercise the set received subvolume ioctl overflow condition should fail safely without aborting the Btrfs transaction or remounting the filesystem read-only. Validate that kernel logs do not show new Btrfs transaction aborts during testing, and confirm affected filesystems remain writable after the test. For production systems, validate by checking kernel package versions against vendor advisories and by monitoring for absence of Btrfs read-only remount events after patch deployment.

Typical attack path

1. Gain low-privileged local access to a Linux system using the Btrfs filesystem.
2. Locate or create Btrfs subvolumes owned by the attacker-controlled user.
3. Invoke the Btrfs set received subvolume ioctl against many owned subvolumes while reusing the same received UUID.
4. Trigger the vulnerable item-overflow path after Btrfs metadata updates have already occurred.
5. Cause the kernel to abort the Btrfs transaction.
6. Force the affected Btrfs filesystem into read-only mode, disrupting writes by applications and system services.

How to detect it

Look for evidence of unexpected Btrfs transaction aborts and read-only remounts in kernel logs, journalctl, dmesg, syslog, and EDR telemetry. Useful log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd syscall logs, EDR process telemetry, container runtime logs, and shell history for users with access to Btrfs subvolumes. Investigate Btrfs filesystems that suddenly become read-only without hardware I/O errors, disk failures, or known maintenance activity. Correlate the timestamp of the first transaction abort with local users, containers, CI jobs, or processes invoking btrfs tooling or direct ioctl calls. If auditd or syscall telemetry is available, search for bursts of ioctl calls referencing Btrfs received subvolume operations or repeated activity against many Btrfs subvolumes by the same low-privileged account. There are no known public threat actors or campaigns tied to this issue in the provided data, so detection should focus on behavioral signs of exploitation rather than actor-specific infrastructure.

• BTRFS: Transaction aborted
• BTRFS: error (device
• BTRFS warning (device
• BTRFS critical (device
• forced readonly
• remounting filesystem read-only
• transaction aborted
• BTRFS_IOC_SET_RECEIVED_SUBVOL
• set received subvol
• BTRFS_UUID_KEY_RECEIVED_SUBVOL

What your security team should do

• Prioritize patching Linux systems that use Btrfs and allow local interactive users, CI jobs, build workloads, containers, or other untrusted code execution.
• Inventory Btrfs usage across servers, developer workstations, container hosts, and storage nodes; systems not using Btrfs are not directly exposed to this flaw.
• Restrict untrusted users from creating or owning Btrfs subvolumes until patched, especially on shared systems.
• Monitor kernel logs for Btrfs transaction aborts and unexpected read-only remounts, and treat them as potential local denial-of-service activity when correlated with untrusted user activity.
• Review auditd, EDR, or system call telemetry for unusual bursts of Btrfs ioctl activity from non-administrative accounts.
• Prepare operational recovery steps for affected systems, including identifying impacted mounts, stopping write-dependent services, remounting or rebooting where safe, and running vendor-recommended Btrfs health checks.
• Because this is not KEV-listed, has no known ransomware use, and has low EPSS, handle it as a targeted local availability risk rather than an internet-facing emergency unless the environment hosts untrusted local workloads.