CVE-2026-46160

Technical summary

The vulnerability exists in the Btrfs filesystem implementation where the last_unlink_trans field is not updated when a directory is removed via rmdir(2). During log replay after an unclean shutdown, this missing update causes the transaction log to reference an inode with an incorrect link count, leading to a critical corruption error ("invalid nlink: has 2 expect no more than 1 for dir") that prevents filesystem mount. The issue manifests only when an open file descriptor exists on the directory at the time of removal, and an fsync is called on that descriptor before the crash occurs.

Business impact

Systems using Btrfs may experience unexpected filesystem corruption and mount failures after power loss or unclean shutdown, resulting in service unavailability and potential data loss. This is particularly relevant for virtualized environments, containers, and dedicated servers relying on Btrfs for storage. Recovery requires manual filesystem repair or restoration from backups, extending recovery time objectives and increasing operational overhead.

Affected systems

Linux systems running the kernel with Btrfs filesystem support are affected. The vulnerability requires a user with local access (not root in many cases) and an active file descriptor on the directory being removed. Btrfs is commonly used in container platforms, virtual machine hosts, and systems prioritizing storage efficiency. The scope is local only; remote exploitation is not possible.

Exploitability

The issue requires local user access and a specific sequence of filesystem operations to trigger. The attack surface is limited: an unprivileged user must open a directory, remove it via rmdir, then fsync the open descriptor before the system crashes or loses power. This could occur accidentally during normal operations or be intentionally triggered by a malicious local user to disrupt service availability. The CVSS score of 5.5 reflects the local-only attack vector and availability impact without confidentiality or integrity exposure.

Remediation

Apply the Linux kernel patch that ensures last_unlink_trans is correctly updated during directory removal. Verify the patch is included in your kernel build and test in a non-production environment first, particularly if you rely heavily on Btrfs. For systems unable to patch immediately, consider using alternative filesystems (ext4, XFS) if feasible, or implement strict access controls to prevent unprivileged users from performing directory removal operations on directories they hold open.

Patch guidance

Check your Linux distribution's kernel update advisories for a patched version addressing CVE-2026-46160. The fix involves modifying the directory removal code path to update the last_unlink_trans field before the inode is deleted. Test the patched kernel in a staging environment that replicates your Btrfs configuration and workload before production deployment. Coordinate the update with your change management process, as kernel updates typically require a reboot.

Detection guidance

Monitor system logs for Btrfs corruption errors during mount or recovery, specifically messages containing "corrupt leaf" or "invalid nlink" errors referencing directories. If such errors occur consistently after unplanned shutdowns, investigate whether the corrupted directories were recently removed and whether processes held open file descriptors. For proactive detection, audit which users and applications open and remove directories frequently, and consider restricting these operations where possible. Collect kernel version and Btrfs-related dmesg output during incidents for forensic analysis.

Why prioritize this

Although the CVSS score is moderate (5.5), the vulnerability should be prioritized because it directly impacts data availability and system recoverability. Unlike many local vulnerabilities, this one affects core filesystem integrity rather than privilege escalation alone. Organizations running Btrfs in production environments should schedule patching within standard security update cycles. The impact is heightened for systems with infrequent reboots or those running in environments where unplanned power loss is plausible (virtualized hosts, edge computing, IoT infrastructure).

Risk score, explained

The CVSS v3.1 score of 5.5 (MEDIUM) reflects an attack vector limited to local access (AV:L), low attack complexity (AC:L), low privilege requirement (PR:L), and no user interaction needed (UI:N). The impact is confined to availability (A:H), with no confidentiality or integrity risk. However, the real-world risk may be elevated in environments where Btrfs is mission-critical or where unplanned shutdowns are common, warranting consideration beyond the numerical score.

Frequently asked questions