CVE-2026-46160 Overview
CVE-2026-46160 is a Linux kernel vulnerability in the Btrfs filesystem. The flaw stems from a missing update to the last_unlink_trans field when a directory is removed via rmdir(2). If a process holds an open file descriptor on the removed directory and subsequently calls fsync on that descriptor, the tree-log can be written in an inconsistent state.
On the next mount after a power failure, log replay fails with -EIO and the kernel reports a corrupt leaf with an invalid nlink count for the directory inode. The result is a filesystem that refuses to replay its tree-log, producing mount failures and potential data loss on the affected volume.
Critical Impact
A local user with normal filesystem access can trigger Btrfs log-replay corruption that prevents the filesystem from mounting after an unclean shutdown.
Affected Products
- Linux kernel — Btrfs filesystem subsystem
- Stable kernel branches receiving the backports referenced in the kernel.org commits
- Linux distributions shipping vulnerable Btrfs code prior to the upstream fix
Discovery Timeline
- 2026-05-28 - CVE-2026-46160 published to the National Vulnerability Database
- 2026-05-28 - Last updated in NVD database
Technical Details for CVE-2026-46160
Vulnerability Analysis
The vulnerability lives in Btrfs directory removal logic. When rmdir(2) succeeds, Btrfs fails to update the directory inode's last_unlink_trans field. This field tracks the most recent transaction in which a child was unlinked, and Btrfs uses it during fsync to decide whether the tree-log requires a full commit to remain consistent.
Because the field is not updated on directory removal, a later fsync issued against an open file descriptor referencing the now-removed directory writes log entries that do not reflect the unlink. The committed tree-log encodes a state in which the parent directory still references the removed child or in which link counts no longer match directory entries.
Upon mount, the log-replay path validates leaf contents and rejects the inode because nlink exceeds what is valid for a directory. The kernel logs messages such as corrupt leaf: ... invalid nlink: has 2 expect no more than 1 for dir and aborts replay with -EIO, leaving the filesystem unmountable until the user discards the log or restores from backup.
Root Cause
The root cause is a missing call to update last_unlink_trans in the directory removal code path. The fsync logic depends on this value to decide between a fast log commit and a full transaction commit. Without the update, Btrfs takes the fast path when the slow path is required for correctness, producing an inconsistent on-disk log.
Attack Vector
Exploitation requires local filesystem access on a Btrfs volume. The reproducer in the upstream advisory uses standard tools: mkdir, mv, xfs_io -c fsync, and rmdir, followed by an unclean shutdown. There is no evidence of remote exploitation or arbitrary code execution. The impact is filesystem availability and integrity on the affected volume.
The vulnerability mechanism is described in the upstream patch series. See the kernel.org commit references for the full technical details and patch context.
Detection Methods for CVE-2026-46160
Indicators of Compromise
- Kernel log entries containing BTRFS critical (device ...): corrupt leaf paired with invalid nlink: has N expect no more than 1 for dir.
- Failed Btrfs mount attempts reporting -EIO during start tree-log replay.
- btrfs check output flagging directory inodes with nlink values exceeding the number of directory back-references.
Detection Strategies
- Monitor dmesg and journalctl -k for Btrfs corrupt leaf and tree-log replay failure messages across Linux endpoints and servers.
- Track running kernel versions against the fixed commits (36fcc2c, 9997572, aa9c3ec, cc3c0a0, fb388eb) to identify hosts that remain exposed.
- Correlate unclean shutdown events with subsequent mount failures on Btrfs volumes to identify systems that may have triggered the bug.
Monitoring Recommendations
- Forward kernel ring buffer logs to a centralized logging or SIEM platform and alert on the BTRFS critical and invalid nlink substrings.
- Maintain an inventory of hosts using Btrfs as their root or data filesystem and prioritize patch tracking for that subset.
- Schedule periodic btrfs scrub and offline btrfs check --readonly runs on critical volumes to surface latent metadata inconsistencies.
How to Mitigate CVE-2026-46160
Immediate Actions Required
- Apply the upstream Btrfs fix or the distribution kernel update that incorporates the referenced commits as soon as it is available for your kernel branch.
- Ensure systems running Btrfs are protected by a UPS or have reliable shutdown procedures to reduce the chance of triggering log-replay failure on the unpatched code.
- Verify backup coverage on Btrfs volumes so that an unmountable filesystem can be restored without data loss.
Patch Information
The fix is delivered through the upstream Linux stable tree. Refer to the relevant commits for the patch content and backport targets: Kernel Patch Commit 36fcc2c, Kernel Patch Commit 9997572, Kernel Patch Commit aa9c3ec, Kernel Patch Commit cc3c0a0, and Kernel Patch Commit fb388eb. Rebuild or upgrade kernels containing these commits and reboot affected systems.
Workarounds
- If a Btrfs volume already fails log replay, mount with -o nologreplay,ro to recover data, then rebuild the filesystem from backup. Use this option only for recovery, as it discards pending log entries.
- Avoid workloads that hold a file descriptor on a directory across rmdir(2) followed by fsync until the patched kernel is deployed.
- Where feasible, switch critical workloads to a filesystem unaffected by this issue until kernel patches are applied.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
