CVE-2026-74596: Linux Kernel fs-verity Privilege Escalation

CVE-2026-74596 Overview

CVE-2026-74596 affects the Linux kernel's file system verification (fs-verity) subsystem. The vulnerability stems from an unnecessary check in setattr_prepare() that verified whether fs-verity was enabled in the kernel. Filesystems can hold fs-verity files even when the fs-verity feature is not enabled in the kernel. Under those conditions, a truncate operation on an fs-verity file could succeed, which the check was intended to prevent. Kernel maintainers resolved the issue by removing the misplaced check.

Critical Impact
A truncate operation on an fs-verity file may succeed when fs-verity is not compiled into the kernel, undermining the integrity guarantees of verity-protected files.

Affected Products

Linux kernel (fs/verity subsystem)
Filesystems supporting fs-verity metadata (for example ext4, f2fs, btrfs)
Stable kernel branches receiving the referenced commits

Discovery Timeline

2026-08-22 - CVE-2026-74596 published to NVD
2026-08-22 - Last updated in NVD database

Technical Details for CVE-2026-74596

Vulnerability Analysis

The Linux kernel's setattr_prepare() path contained a check that inspected whether fs-verity support was compiled and enabled in the running kernel. Fs-verity is a read-only file integrity feature that seals a file after enabling and blocks modifications, including truncation. The check assumed that files protected by fs-verity only exist on systems where the feature is active in the kernel. That assumption does not hold. A filesystem image can carry fs-verity metadata on files while being mounted by a kernel that lacks fs-verity support. In that case, setattr_prepare() bypasses the protection logic and allows attribute changes such as truncation on files that should remain immutable. The fix removes the enablement check so that verity-protected files are recognized and guarded regardless of the kernel build configuration. See the kernel commit 2d2b2ed7 and kernel commit d2f96bcb for the resolution.

Root Cause

The root cause is a conditional gate around the fs-verity attribute check inside setattr_prepare(). The gate depended on kernel-level fs-verity availability rather than on the per-inode verity flag. This left verity-flagged inodes unprotected on kernels without the feature enabled.

Attack Vector

A local user with permission to modify an fs-verity flagged file on a filesystem mounted by a kernel without fs-verity support can issue a truncate() syscall against that file. The syscall succeeds, altering content that the verity metadata is meant to seal. The vulnerability is local and requires filesystem write access to the target file.

No verified public exploit code has been published. Refer to the linked commits for the exact code path.

Detection Methods for CVE-2026-74596

Indicators of Compromise

Unexpected size changes or truncation events on files that carry the fs-verity inode flag
Successful truncate() or ftruncate() syscalls against files known to be verity-sealed
Verity signature or Merkle-tree verification failures during subsequent reads

Detection Strategies

Audit kernel build configuration on production hosts to confirm CONFIG_FS_VERITY state and correlate with filesystems containing verity metadata
Compare current file sizes and hashes of verity-sealed artifacts against a known-good baseline
Enable Linux audit rules on truncate, ftruncate, and open with O_TRUNC for paths that host verity-protected binaries or containers

Monitoring Recommendations

Forward auditd and kernel logs to a central analytics platform and alert on truncate operations targeting sealed asset paths
Track kernel version and patch level across the fleet to identify hosts running unpatched stable branches
Monitor package integrity of verity-protected content such as APEX images, container layers, or signed application bundles

How to Mitigate CVE-2026-74596

Immediate Actions Required

Apply the upstream fix from the referenced stable kernel commits to affected branches
Enable CONFIG_FS_VERITY on kernels that mount filesystems containing verity-flagged files
Restrict write access to verity-sealed files through standard filesystem permissions and mandatory access controls

Patch Information

The issue is resolved by removing the fs-verity enablement check from setattr_prepare(). The upstream fix is available in kernel commit 2d2b2ed7bdcc and the backport in kernel commit d2f96bcb89d3. Distribution vendors will incorporate these commits into their supported kernel packages.

Workarounds

Mount filesystems containing verity-protected files read-only where operationally feasible
Avoid mounting filesystems that carry fs-verity metadata on kernels without fs-verity compiled in
Use SELinux or AppArmor policies to deny write and truncate operations on sealed file paths until the patch is deployed

bash

# Verify fs-verity support and kernel version
grep CONFIG_FS_VERITY /boot/config-$(uname -r)
uname -r

# Check verity flag on a file
lsattr /path/to/protected/file