CVE-2026-43361

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel Btrfs filesystem. A user with permission to operate on a Btrfs subvolume they own can repeatedly create read-only snapshots of a previously received subvolume until Btrfs overflows the metadata item used for received subvolume UUID tracking. The overflow causes Btrfs snapshot creation to fail with error -75 and aborts the active filesystem transaction. When Btrfs aborts a transaction, it typically remounts or forces the affected filesystem into read-only mode to preserve consistency, causing writes to fail until administrative recovery or remount/reboot actions are taken. The vulnerability does not directly provide code execution, privilege escalation, or data disclosure, but it can cause high availability impact on systems using Btrfs where unprivileged or low-privileged users can create/send/receive/snapshot subvolumes.

Why it matters to the business

A local user can intentionally make a Btrfs-backed filesystem stop accepting writes, disrupting workloads, containers, user home directories, backup repositories, or systems that rely on Btrfs snapshots. The main risk is operational outage, failed writes, service instability, and possible recovery work for administrators. Exploitation requires local access and suitable Btrfs subvolume permissions, and the current EPSS score is very low with no known KEV listing or known ransomware use, so broad internet-scale exploitation is unlikely; however, multi-user Linux systems, build hosts, backup servers, developer workstations, and container hosts using Btrfs should treat it as a meaningful local availability risk.

How an attack unfolds

An attacker first obtains local access to a Linux system that uses Btrfs and identifies a mounted Btrfs filesystem where they can create or control subvolumes. They create or use a subvolume, mark it read-only so it can be sent, and perform a Btrfs send/receive operation to create a received subvolume containing received UUID metadata. They then repeatedly create read-only snapshots of that received subvolume. Each snapshot operation adds UUID-related metadata until the Btrfs leaf item for received subvolume UUID tracking exceeds the maximum storable item size. Once the limit is hit, Btrfs reports a value-too-large condition, logs warnings such as an insert UUID item failure, aborts the transaction, and transitions the affected filesystem into read-only mode. At that point, normal write operations against that filesystem fail with read-only filesystem errors, disrupting services or users dependent on that storage.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the Btrfs fix for transaction aborts when snapshotting received subvolumes. No exact fixed kernel versions were provided in the input, so remediation should be based on vendor advisories and distribution package changelogs for the running kernel stream. After installing the fixed kernel, reboot into the updated kernel because kernel filesystem fixes are not effective until the patched kernel is running. As interim mitigation, restrict local users' ability to create Btrfs subvolumes, snapshots, and send/receive workflows on shared filesystems; avoid granting write access to Btrfs mounts used by multiple untrusted users; monitor and limit automated snapshot creation; and isolate Btrfs-backed infrastructure where untrusted users can execute commands. If a filesystem has already been forced read-only, preserve logs, stop dependent services as needed, investigate for repeated snapshot activity, and follow vendor-recommended Btrfs recovery steps before remounting read-write.

How to confirm the fix worked

Confirm exposure by checking whether systems use Btrfs and whether local users can create snapshots or perform Btrfs send/receive operations. Validate remediation by verifying the running kernel version after reboot and confirming it corresponds to a vendor release containing the Btrfs fix. Functional validation can include reviewing vendor test cases or safely testing in a non-production Btrfs environment that repeated snapshots of a received subvolume no longer abort the transaction or force the filesystem read-only. Do not run destructive reproducer scripts on production systems. Check current mounts with filesystem tooling, verify Btrfs filesystems are not unexpectedly read-only, and review kernel logs for historical Btrfs transaction abort messages associated with snapshot creation.

Typical attack path

1. Gain local shell access or execute code as a low-privileged user on a Linux system using Btrfs.
2. Find a Btrfs mount where the user owns or can operate on subvolumes.
3. Create a subvolume and set it read-only so it can be used with Btrfs send.
4. Use btrfs send and btrfs receive to create a received subvolume with received_uuid metadata.
5. Repeatedly create read-only snapshots of the received subvolume.
6. Trigger Btrfs metadata item overflow for received subvolume UUID tracking.
7. Cause Btrfs to abort the active transaction and force the filesystem into read-only mode.
8. Leverage the resulting write failures to disrupt applications, users, containers, or system operations.

How to detect it

Look for evidence of Btrfs transaction aborts and read-only transitions in kernel logs, system journals, syslog, audit logs, and command history. Key log sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd journal entries for the kernel, auditd execve records, shell history, and EDR process telemetry. Search for Btrfs warnings around failed UUID item insertion, transaction aborts with error -75, create_pending_snapshot stack traces, and user-facing btrfs command errors such as 'Value too large for defined data type' followed by 'Read-only file system'. Correlate these events with repeated executions of 'btrfs subvolume snapshot', 'btrfs send', 'btrfs receive', and 'btrfs property set ... ro true'. For suspected exploitation, identify the user account running btrfs commands, the affected mount point, the number and timing of snapshot creations, and whether the filesystem became read-only immediately afterward. Because the vulnerability is local and command-driven, there are no reliable remote network indicators; detection should focus on host logs, process execution, filesystem state changes, and abnormal snapshot volume.

• BTRFS warning (device
• insert uuid item failed -75
• type 252!
• BTRFS: Transaction aborted (error -75)
• WARNING: fs/btrfs/transaction.c
• create_pending_snapshot
• create_pending_snapshots
• btrfs_commit_transaction
• ERROR: Could not create subvolume: Value too large for defined data type
• ERROR: Could not create subvolume: Read-only file system
• btrfs subvolume snapshot -r
• btrfs send
• btrfs receive
• btrfs property set
• ro true
• Read-only file system
• Value too large for defined data type

What your security team should do

• Inventory Linux systems using Btrfs, prioritizing multi-user servers, backup/snapshot infrastructure, developer hosts, container hosts, and systems where untrusted users have shell access.
• Patch affected Linux kernels through the relevant OS/vendor update channel and reboot into the corrected kernel.
• Temporarily restrict Btrfs subvolume, snapshot, send, and receive operations to trusted administrators where patching is delayed.
• Monitor kernel logs and SIEM telemetry for Btrfs transaction aborts, insert UUID item failures, and sudden read-only remount behavior.
• Investigate users or automation that created unusually high volumes of Btrfs snapshots, especially snapshots of received subvolumes.
• Add operational alerting for filesystems unexpectedly entering read-only mode, as this may be the first visible service-impact symptom.
• For shared systems, review filesystem permissions and ownership models so low-privileged users cannot disrupt shared Btrfs filesystems.
• Document recovery procedures for Btrfs read-only transaction abort events, including service shutdown, evidence preservation, patching, and controlled remount/reboot steps.