CVE-2026-98534: ipe: fix use-after-free when auditing a newly loaded policy
In the Linux kernel, the following vulnerability has been resolved:
ipe: fix use-after-free when auditing a newly loaded policy
newpolicy() audits the policy after ipenewpolicyfsnode() publishes it and drops the new directory's inode lock. A concurrent delete can free the policy while ipeauditpolicyload() is still using it.
Audit the successful load under that lock.
[FW: remove model name according to latest guideline]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
Audit the successful policy load while holding the new directory's inode lock, before releasing the lock, so a concurrent delete cannot free the policy while ipe_audit_policy_load() is using it.
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
Systems using the Linux kernel's IPE policy functionality may be exposed when a newly loaded policy can be deleted concurrently with its load audit. The issue occurs after the policy is published and the new directory inode lock has been released.
What does an attacker or concurrent actor need to trigger the issue?
A policy deletion must race with loading a new policy. The deletion can free the policy while the load-audit path is still accessing it.
How can I determine whether the fix is present?
Check whether your kernel includes one of the referenced stable commits: b72d6c72b4bfbc021e8e127fa13e0f27d09be737, 48f7d0233c3cc8d986d1177d0e5dd4af435e7265, or e9015d32752fa228ef2f0e07fd93fc53a4a4c723. The corrected behavior performs the successful load audit while the relevant inode lock is held.