Cloudanix VulnDB

CVE-2026-98862

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A race condition in the Linux kernel's auditing code can let one process free memory that another process is still using, potentially crashing the system or allowing an attacker to take control.

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

What it actually does

Use-after-free in audit_mark_compare() triggered when kill_rules() drops an exe mark before the rule is unlinked from RCU-visible filter lists, allowing fsnotify to free the mark during concurrent rule evaluation on mixed AUDIT_DIR/AUDIT_EXE trees.

Why it matters to the business

Kernel memory corruption on Linux systems that use audit rules watching executables; can cause crashes, information leaks, or local privilege escalation, especially on servers with active audit configurations.

How an attack unfolds

An attacker with CAP_AUDIT_CONTROL installs an AUDIT_EXE rule, then races directory removal against another process evaluating that rule; fsnotify frees the mark while the reader still holds a reference, leading to the UAF in audit_mark_compare.

How to fix it

Upgrade to a Linux kernel containing the fix that unlinks rules from RCU-visible lists first, retains them on tree->rules, and waits a full RCU grace period before freeing any exe marks.

How to confirm the fix worked

Verify kernel version contains the commit titled "audit: fix exe mark UAF in kill_rules()"; confirm absence of the KASAN report in audit_mark_compare after directory prune workloads; run audit rule stress tests with mixed DIR/EXE rules.

Typical attack path

  1. Obtain CAP_AUDIT_CONTROL and add AUDIT_EXE rule via AUDIT_ADD_RULE
  2. Trigger concurrent directory prune that invokes kill_rules() on the same tree
  3. Force a second task to reach audit_mark_compare() before RCU grace period completes
  4. Trigger KASAN-detected slab-use-after-free or exploit for arbitrary read/write

How to detect it

Search kernel logs for KASAN reports mentioning audit_mark_compare or slab-use-after-free during audit tree pruning; inspect audit logs for concurrent AUDIT_ADD_RULE and directory removal operations; correlate with processes holding CAP_AUDIT_CONTROL.

What your security team should do

  • Patch kernel immediately on any system exposing audit rules to untrusted users or containers
  • Temporarily disable AUDIT_EXE rules if patching is delayed
  • Monitor for KASAN or audit-related oops in production workloads
  • Review audit configuration for unnecessary executable watches

The record

In the Linux kernel, the following vulnerability has been resolved: audit: fix exe mark UAF in kill_rules() kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry->rule.exe before removing the rule from the RCU-visible filter lists. After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free. KASAN reports: BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0 Unlink the published rules from the RCU-visible lists and retain them on tree->rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait.

Affected packages

Ecosystem Package Introduced Fixed