Bug 2453804 (CVE-2026-23409)

Summary:	CVE-2026-23409 kernel: apparmor: fix differential encoding verification
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	Keywords:	Security
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in AppArmor, a security module in the Linux kernel. This vulnerability occurs due to incorrect verification of differential encoding chains, which are designed to prevent malicious loops. An attacker could exploit this flaw by crafting a specially designed differential encoding chain, causing the system to misinterpret it as already verified. This could lead to a bypass of security policies and potentially result in unexpected system behavior or a denial of service.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-04-01 10:02:41 UTC

In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix differential encoding verification

Differential encoding allows loops to be created if it is abused. To
prevent this the unpack should verify that a diff-encode chain
terminates.

Unfortunately the differential encode verification had two bugs.

1. it conflated states that had gone through check and already been
   marked, with states that were currently being checked and marked.
   This means that loops in the current chain being verified are treated
   as a chain that has already been verified.

2. the order bailout on already checked states compared current chain
   check iterators j,k instead of using the outer loop iterator i.
   Meaning a step backwards in states in the current chain verification
   was being mistaken for moving to an already verified state.

Move to a double mark scheme where already verified states get a
different mark, than the current chain being kept. This enables us
to also drop the backwards verification check that was the cause of
the second error as any already verified state is already marked.

Comment 1 Alexander B 2026-04-01 10:37:56 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026040113-CVE-2026-23409-ae18@gregkh/T