CVE-2026-80843 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix xfrm_state_construct() auth-trunc leak
attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes).
xfrm_state_construct() then treats !x->props.aalgo as "no auth algorithm attached yet" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer.
Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel's IPsec implementation, specifically within the XFRM subsystem, contains a memory management flaw in the xfrm_state_construct function that leads to resource leaks and potential instability during authentication algorithm configuration. This vulnerability arises from an incorrect assumption regarding how authentication algorithms are registered and tracked within the state structure. The core issue lies in the logic used to determine whether an authentication algorithm has already been attached to an XFRM state object. Historically, the code relied on checking if x->props.aalgo was non-zero as a proxy for determining if an auth algorithm was present. However, this heuristic fails when certain valid cryptographic algorithms, such as cmac(aes), do not have a corresponding sadb_alg_id assigned in the kernel's internal mapping tables. In these specific cases, attach_auth_trunc() successfully allocates and attaches the authentication algorithm object to x->aalg but leaves x->props.aalgo at zero because no standard identifier exists for that particular configuration.
This discrepancy creates a critical logic error where subsequent operations misinterpret the state of the XFRM structure. When the construction process continues, it checks x->props.aalgo and, finding it to be zero, incorrectly concludes that no authentication algorithm has been attached yet. Consequently, the code proceeds to call attach_auth() again in an attempt to set up authentication. This second attachment overwrites the pointer stored in x->aalg with a new allocation for the replacement algorithm. The original allocated memory block from the first successful attach operation is now orphaned; its reference count is not decremented and it is never freed because the code only tracks the final state of x->props.aalgo rather than maintaining an accurate record of all allocations made to x->aalg during the construction phase.
The operational impact of this flaw manifests primarily as a memory leak within the kernel space. Each time an XFRM state is constructed using an algorithm like cmac(aes) that lacks a sadb_alg_id, one allocation unit for the authentication algorithm structure remains permanently allocated until system reboot or module unload. While individual leaks may seem negligible in isolation, they accumulate over time as new security associations are established, particularly on systems with high network throughput or frequent IPsec tunnel re-negotiations. This gradual consumption of kernel memory can lead to increased pressure on the slab allocator and potentially contribute to out-of-memory conditions under sustained load. Furthermore, if a failure occurs during later stages of state construction after this leak has happened but before full teardown, the cleanup routines may only free the replacement pointer, leaving the initial allocation permanently lost in the system's memory footprint.
From a vulnerability classification perspective, this issue aligns with CWE-401, which describes missing release of memory after effective usage. The flaw represents an improper resource management pattern where allocated resources are not properly released due to logic errors that cause references to be overwritten without prior deallocation. In the context of ATT&CK techniques related to defense evasion or persistence through system resource exhaustion, while this specific bug is primarily a stability and reliability issue rather than a direct exploitation vector for privilege escalation, it degrades the integrity and availability of the security subsystem itself. By allowing memory leaks within core networking components, an attacker could theoretically contribute to denial-of-service conditions by forcing repeated state constructions that trigger this leak path repeatedly.
Mitigation strategies focus on correcting the logic used to track attachment status rather than relying on indirect indicators like sadb_alg_id presence. The primary fix involves modifying xfrm_state_construct() to directly inspect whether x->aalg is already populated with a valid pointer before attempting any further authentication attachments. This ensures that if an algorithm has been successfully attached, even in the absence of a standard identifier, subsequent steps recognize this state and skip redundant attachment procedures. System administrators should apply kernel updates provided by their distribution vendors that include patches for the XFRM subsystem addressing this specific logic error. Until such updates are applied, monitoring system memory usage patterns associated with network stack activities may help identify anomalous growth indicative of these leaks, although direct mitigation requires patching the underlying kernel code to enforce strict reference tracking and proper deallocation protocols during state construction failures or completions.