CVE-2026-46160

What it actually does

This is a local Linux kernel Btrfs filesystem consistency flaw in directory removal handling. When a directory is removed while a process still holds an open file descriptor to it, Btrfs may fail to update the directory inode's last_unlink_trans state. If that directory is then fsynced and the system loses power or crashes before state is safely persisted, subsequent Btrfs tree-log replay during mount can encounter inconsistent metadata, fail with EIO, and prevent the filesystem from mounting normally. The primary impact is availability loss through filesystem mount failure or recovery disruption; the provided scoring indicates local access with low attack complexity and low privileges, with no expected confidentiality or direct integrity impact beyond filesystem metadata inconsistency.

Why it matters to the business

Systems using Btrfs can suffer service outages if a local user or workload triggers the vulnerable directory operation sequence and the host later crashes or loses power. The practical consequence is downtime while administrators repair, roll back, restore, or recover the affected filesystem. This is most relevant for Linux servers, appliances, workstations, containers, build systems, and storage nodes that use Btrfs for active writable filesystems. The vulnerability is not listed in CISA KEV, has low EPSS, and has no known mature public exploitation in the provided data, so it is lower urgency than internet-facing remote code execution issues, but it can still materially affect availability on Btrfs-backed systems.

How an attack unfolds

An attacker needs local ability to perform filesystem operations on a vulnerable Btrfs mount. They create and modify directories, move a child directory out so the parent becomes empty, keep a file descriptor open to the parent directory, remove the directory by path, and then fsync the still-open directory file descriptor. The flaw is not fully realized until an unclean shutdown, crash, or power loss occurs after the problematic fsync sequence. On the next mount, Btrfs attempts tree-log replay and can detect invalid directory link metadata, resulting in EIO and failed mount/recovery. This makes exploitation a local denial-of-service path against systems where untrusted or semi-trusted users can write to Btrfs filesystems and where a crash/reboot condition can occur or be induced.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the upstream Btrfs fix for missing last_unlink_trans update during directory removal. Because no exact fixed package versions were provided, use the patched kernel versions published by the relevant Linux distribution or kernel supplier and confirm the changelog references the Btrfs directory removal/fsync fix. Prioritize systems that use Btrfs for root filesystems, service data, virtual machine images, container storage, build directories, or shared writable areas. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting write access to Btrfs mounts, moving untrusted workloads to non-Btrfs storage, enforcing least privilege on directories stored on Btrfs, and ensuring reliable power/crash protection such as UPS coverage and orderly shutdown procedures. Maintain current backups and tested recovery procedures for Btrfs-backed data.

How to confirm the fix worked

Confirm whether hosts use Btrfs by checking mounted filesystems with commands such as findmnt -t btrfs, mount | grep btrfs, or lsblk -f. Confirm remediation by verifying the running kernel package is at or above the distribution's fixed release and that vendor advisories/changelogs include the Btrfs last_unlink_trans or directory removal fsync fix. After patching, reboot into the fixed kernel and verify with uname -r and package-manager queries. For exposure validation, identify writable Btrfs mounts accessible to non-root users or untrusted services. For operational validation, confirm Btrfs filesystems mount cleanly after reboot and review dmesg or journal logs for absence of Btrfs tree-log replay failures, corrupt leaf messages, invalid nlink errors, or EIO mount failures.

Typical attack path

1. Obtain local access to a Linux system with a writable Btrfs filesystem.
2. Create a directory hierarchy on the Btrfs mount and perform metadata changes that make the target directory participate in fsync/logging behavior.
3. Move child directories away so the parent directory becomes empty.
4. Open a file descriptor to the now-empty parent directory.
5. Remove the parent directory by path while retaining the open directory file descriptor.
6. Call fsync on the retained directory file descriptor.
7. Wait for, trigger, or combine the sequence with an unclean shutdown, crash, or power loss.
8. During the next mount, rely on Btrfs tree-log replay failing due to inconsistent directory metadata, causing filesystem availability loss.

How to detect it

Look for evidence of prior exploitation or triggering in kernel logs, system journals, boot logs, and filesystem recovery records. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, distribution crash logs, and monitoring alerts for failed mounts. Search around reboot, crash, power-loss, or unclean-shutdown events for Btrfs tree-log replay followed by EIO errors, corrupt leaf reports, invalid nlink errors, page dumps, or mount failures. Correlate suspicious filesystem activity before the outage where available, such as auditd records for mkdir, mv/rename, rmdir, open/openat of directories, and fsync on Btrfs paths by the same user or process. Since the exploit sequence uses normal local filesystem operations, there may be no distinctive malicious process or network indicator; detection is strongest when Btrfs recovery errors occur after an unclean shutdown on a vulnerable kernel. If auditd or eBPF telemetry is deployed, hunt for unusual repeated directory creation, moving, removal, and fsync activity on writable Btrfs mounts by non-administrative users shortly before a crash or reboot.

• BTRFS info (device
• start tree-log replay
• BTRFS critical (device
• corrupt leaf: root=5
• invalid nlink: has 2 expect no more than 1 for dir
• page dumped because: eb page dump
• aops:btree_aops [btrfs]
• first mount of filesystem
• log replay failed
• tree-log replay
• BTRFS: error
• BTRFS error
• mount: wrong fs type, bad option, bad superblock
• EIO
• rmdir(
• fsync

What your security team should do

• Inventory Linux systems using Btrfs and rank them by business criticality and whether untrusted local users or workloads can write to Btrfs mounts.
• Patch affected systems through the operating system vendor's fixed kernel release, then reboot to ensure the fixed kernel is active.
• Prioritize Btrfs-backed production services, storage nodes, container hosts, developer/build systems, and systems with shared writable directories.
• Restrict local access and write permissions on Btrfs mounts until patched, especially for multi-user systems and sandboxed workloads with filesystem write access.
• Review backup, snapshot, and disaster recovery procedures for Btrfs-backed filesystems, and verify restore capability.
• Monitor kernel logs and SIEM telemetry for Btrfs tree-log replay failures, corrupt leaf messages, invalid nlink errors, and EIO mount failures.
• Treat post-crash Btrfs mount failures as potentially related to this flaw and preserve logs before repair attempts.
• Because EPSS is low and there is no KEV listing or known mature exploit in the provided data, schedule remediation according to normal kernel maintenance timelines unless the system is critical or multi-tenant.