CVE-2026-98534

What it actually does

Race condition in Linux kernel IPE module allows use-after-free: new_policy() publishes the policy and drops the inode lock before auditing, enabling a concurrent delete to free the policy object while ipe_audit_policy_load() still references it.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel crashes or attempt code execution, causing downtime, data loss, or full system compromise on servers or devices enforcing IPE policies.

How an attack unfolds

An attacker with permissions to manage IPE policy nodes loads a new policy, then races a deletion of the newly created directory entry; the audit handler dereferences the now-freed policy structure, enabling memory corruption primitives.

How to fix it

Apply upstream kernel patches that perform the successful-load audit while still holding the inode lock; rebuild and deploy updated kernels to all affected systems.

How to confirm the fix worked

Confirm the fix by inspecting kernel source for the audit call moved under the lock in new_policy(), or verify updated kernel builds contain the referenced commit resolving the IPE policy UAF.

Typical attack path

1. Gain local access and permissions to create/delete IPE policy filesystem nodes
2. Invoke policy load operation that publishes the node and releases the lock
3. Concurrently trigger policy node deletion from another context
4. Force the audit callback to access the freed policy object

How to detect it

Review kernel logs and audit trails for oops/panic messages referencing IPE policy structures, unusual concurrent policy load and delete sequences, or warnings from memory safety checkers around ipe_new_policyfs_node.

What your security team should do

• Expedite deployment of patched kernels on all IPE-enabled systems
• Temporarily restrict unprivileged policy load/delete operations where feasible
• Enable kernel hardening features such as KASAN or lockdep for early detection of similar races