Cloudanix VulnDB

CVE-2026-99051

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's file verification feature can let a logged-in user crash the system or gain full control by racing memory operations on verified files.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in fsverity due to rhashtable_lookup_fast under rcu_read_lock without synchronizing removal of fsverity_info from the hashtable for different inodes, allowing concurrent access to a freed struct containing rhash_head and inode pointer.

Why it matters to the business

Local attackers on Linux systems using fsverity can trigger kernel memory corruption leading to crashes, data corruption, or full system compromise, risking service outages and requiring urgent kernel updates across fleets.

How an attack unfolds

An attacker with local access triggers concurrent calls to __fsverity_get_info on different inodes while fsverity_remove_info frees the struct, racing the RCU grace period and dereferencing freed memory via the rhashtable entry.

How to fix it

Apply the upstream kernel patch that RCU-delays freeing of struct fsverity_info after rhashtable removal; rebuild and deploy updated kernels to all affected systems.

How to confirm the fix worked

Confirm presence of the RCU-delay change in fs/verity/verify.c or fs/verity/info.c; test concurrent inode verity operations under load to ensure no UAF reports in kernel logs.

Typical attack path

  1. Obtain local user access on a Linux system with fsverity enabled
  2. Identify or create multiple inodes using fsverity
  3. Trigger concurrent __fsverity_get_info lookups while forcing inode eviction or verity removal on one inode
  4. Exploit the resulting use-after-free for memory corruption or information leak

How to detect it

Search kernel logs for oops or warnings referencing fsverity_info, rhashtable_lookup_fast, or __fsverity_get_info around inode eviction events; inspect crash dumps for use-after-free patterns in verity code paths.

What your security team should do

  • Prioritize kernel updates within 7 days given the local privilege-escalation potential
  • Audit systems for fsverity usage via mount options and verity-enabled files
  • Enable kernel hardening features such as KASAN in test environments to catch similar issues
  • Monitor for related patches in distribution security feeds

The record

In the Linux kernel, the following vulnerability has been resolved: fsverity: RCU-delay the freeing of struct fsverity_info __fsverity_get_info() calls rhashtable_lookup_fast(), which just uses rcu_read_lock() and doesn't directly synchronize with fsverity_remove_info(). For the same inode this isn't a problem: its fsverity_info is removed only at inode eviction time or upon failure to enable verity, when the inode no longer needs its fsverity_info and it will no longer be accessed via that inode. However, this is broken and can cause a use-after-free for concurrent __fsverity_get_info() for *different* inodes. Those rely on following fsverity_info::rhash_head in the rhashtable under rcu_read_lock() only. They also use fsverity_info::inode to do the key comparison. Fix this by RCU-delaying the freeing of 'struct fsverity_info' after it's been removed from the rhashtable.

Affected packages

Ecosystem Package Introduced Fixed