CVE-2026-43360

What it actually does

This is a local denial-of-service flaw in the Linux kernel Btrfs filesystem. A low-privileged local user who can create files on a writable Btrfs filesystem can intentionally create many filenames that collide in Btrfs directory item hashing. When enough colliding names are packed into the same directory item, an internal leaf-size limit can be exceeded. Instead of handling the condition safely, vulnerable kernels may abort the active Btrfs transaction and force the filesystem into read-only mode. The issue does not provide code execution, privilege escalation, or direct data disclosure, but it can disrupt availability for any workloads depending on the affected filesystem.

Why it matters to the business

Systems using writable Btrfs volumes can be disrupted by an unprivileged local account, containerized workload, build job, or application user with file-create permissions. The primary business risk is service interruption: applications may fail to write data, package managers and logging may break, databases or stateful services may degrade or stop, and manual recovery may be required to remount or repair the filesystem. The CVSS availability impact is high, but exploitation requires local access and current public exploitation signals are low: EPSS is 0.00163, it is not listed in CISA KEV, and no ransomware use is indicated.

How an attack unfolds

An attacker first needs local access to a Linux system or workload that can write to a Btrfs-mounted filesystem. They identify or create a directory on that filesystem where they have permission to create files. The attacker then creates a set of specially chosen filenames that produce the same Btrfs directory hash. As the number of colliding entries grows, Btrfs attempts to store them in the same directory item. Once the item exceeds the filesystem leaf-size constraints, the vulnerable kernel mishandles the condition and aborts the filesystem transaction. Btrfs then protects consistency by switching the filesystem to read-only mode. From the attacker’s perspective, the result is a denial of service: writes to the affected filesystem fail until administrators intervene and the system is patched or rebooted/remounted as appropriate.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the Btrfs fix for transaction aborts caused by directory name-hash collisions. No exact fixed upstream or distribution package versions were provided in the input, so use the security advisory from the relevant Linux distribution or kernel supplier and verify that the patch for this issue is included. Prioritize systems where untrusted users, CI jobs, containers, shared hosting workloads, or applications can create arbitrary filenames on Btrfs volumes. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting write access to Btrfs filesystems, isolating untrusted workloads away from Btrfs-backed writable paths, enforcing quotas where appropriate, and monitoring for abnormal file-creation bursts or Btrfs read-only remount events. Recovery after exploitation may require stopping affected services, preserving logs for investigation, remounting or rebooting, and running normal Btrfs health checks according to vendor guidance.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems that use Btrfs for writable filesystems and checking their running kernel versions against distribution security advisories. Use commands such as `findmnt -t btrfs`, `mount | grep btrfs`, `uname -r`, and package-manager queries to identify affected systems. Validate remediation by confirming the running kernel is the patched version after reboot, not merely that an updated package is installed. Review `dmesg`, `journalctl -k`, and system logs for Btrfs transaction abort or forced read-only messages. In non-production test environments only, regression testing can verify that creating colliding filenames no longer causes a transaction abort or read-only remount.

Typical attack path

1. Gain local shell, application-level file-write capability, or workload execution on a Linux system using Btrfs.
2. Locate a writable directory on a Btrfs filesystem.
3. Create many files with deliberately selected names that collide under Btrfs directory hashing.
4. Trigger the Btrfs directory item packing limit during file creation.
5. Cause the kernel to abort the Btrfs transaction.
6. Filesystem is forced read-only, causing writes and dependent services to fail.

How to detect it

Look for evidence that a writable Btrfs filesystem unexpectedly switched to read-only mode after file-creation activity. Primary sources are kernel logs (`dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`), audit logs if file creation auditing is enabled, EDR file telemetry, and service logs showing sudden `read-only file system` or write failures. Hunt for clusters of unusual file creations in a single directory, especially many long or high-entropy filenames created by the same low-privileged user or workload immediately before Btrfs errors. Correlate Btrfs transaction abort messages with process execution, shell history, auditd `creat/openat` events, container logs, CI job logs, and user session records. Because the vulnerability does not require network traffic and does not leave a unique exploit binary, detection is behavioral: transaction aborts, forced read-only remounts, and abnormal filename-collision creation patterns are the strongest indicators.

• BTRFS: Transaction aborted
• BTRFS: forced readonly
• BTRFS: error (device
• Remounting filesystem read-only
• readonly filesystem
• read-only file system
• transaction aborted
• btrfs: transaction abort
• mkfs.btrfs -f --nodesize 4K
• exploit-hash-collisions.sh
• foobar
• %a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6jZnkDtUUru1t@RouaUe_L:@xGkbO3nCwvLNYeK9vhE628gss:T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC
• AQci3EUB%shMsg-N%frgU:02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB:=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmqrMiL9-Y0I_l5Fnam04CGIg=8@U:Z

What your security team should do

• Inventory all Linux systems using writable Btrfs filesystems, especially shared systems, developer workstations, CI runners, container hosts, and multi-user servers.
• Patch affected kernels through the appropriate distribution or vendor channel and reboot into the fixed kernel.
• Prioritize systems where low-privileged or untrusted users can create arbitrary filenames on Btrfs volumes.
• Add monitoring for Btrfs transaction aborts, forced read-only remounts, and sudden write failures on Btrfs-backed services.
• Review local access controls and workload isolation to reduce opportunities for untrusted users or containers to write directly to shared Btrfs paths.
• If read-only remount events occurred, preserve kernel logs and audit data before remediation, then assess service impact and filesystem health.
• Do not treat low EPSS or non-KEV status as a reason to ignore patching on multi-user Btrfs systems, because exploitation is simple once local write access exists.