CVE-2026-80843

What it actually does

Memory leak in Linux kernel XFRM where attach_auth_trunc() allocates x->aalg for algorithms lacking sadb_alg_id (e.g., cmac(aes)) but x->props.aalgo remains zero, causing xfrm_state_construct() to overwrite the pointer via attach_auth() without freeing the original allocation; only the replacement is released on teardown.

Why it matters to the business

Gradual kernel memory exhaustion on IPsec-enabled systems using affected authentication algorithms, resulting in performance degradation, increased resource consumption, or eventual denial of service after prolonged operation; low EPSS and absence from KEV indicate limited immediate widespread risk despite 25 days since publication.

How an attack unfolds

An attacker triggers repeated XFRM state constructions with specific auth algorithms that bypass the props.aalgo check, causing pointer overwrites and leaked allocations; no known threat actors or ransomware campaigns are associated, and exploitation requires local or privileged access to IPsec configuration.

How to fix it

Apply the upstream kernel patch that replaces the x->props.aalgo inference with a direct check for whether x->aalg is already attached; monitor for future stable releases containing the xfrm_state_construct() auth-trunc leak fix.

How to confirm the fix worked

Inspect kernel source or git history for the updated condition checking x->aalg prior to attach_auth() calls; test XFRM state construction with cmac(aes) and confirm no repeated allocations without corresponding frees via memory profiling tools.

Typical attack path

1. Configure or induce XFRM state setup using an auth algorithm such as cmac(aes) with no sadb_alg_id
2. Invoke xfrm_state_construct() which misdetects attached auth state
3. Trigger overwrite of x->aalg pointer without freeing prior allocation
4. Repeat to accumulate leaked memory until system impact occurs

How to detect it

Examine kernel logs and memory accounting for repeated XFRM allocation patterns without matching releases; correlate with IPsec policy changes or state construction events.

What your security team should do

• Prioritize kernel upgrades on all systems handling IPsec traffic within standard patch cycles
• Review XFRM configuration to identify use of algorithms without sadb_alg_id
• Track memory metrics on affected hosts for early signs of anomalous growth