CVE-2026-64222 in Linux
Summary
by MITRE • 07/24/2026
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: avoid double free of pool->stack on AQ init failure
otx2_pool_aq_init() frees pool->stack when mailbox sync or retry allocation fails, but leaves the pointer unchanged. Later, otx2_sq_aura_pool_init() unwinds the partial setup through otx2_aura_pool_free(), which frees pool->stack again. The CN20K-specific cn20k_pool_aq_init() implementation has the same bug in its corresponding error path.
Set pool->stack to NULL immediately after the local free so the shared cleanup path does not free the same stack again while cleaning up partially initialized pool state.
The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3.
Runtime validation was not performed because reproducing this path requires OcteonTX2/CN20K hardware.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/24/2026
This vulnerability exists within the Linux kernel's OcteonTX2 network driver implementation, specifically affecting the pool management subsystem used for hardware resource allocation. The issue manifests as a double free condition that occurs during the initialization of AQ (Admin Queue) structures within the otx2_pool_aq_init() function, representing a critical memory safety flaw that can lead to system instability and potential exploitation. The vulnerability affects both the generic octeontx2-pf driver and the CN20K-specific implementation, demonstrating a widespread issue in the network driver's resource cleanup mechanisms.
The technical flaw stems from improper pointer management during error handling within the pool initialization sequence. When otx2_pool_aq_init() encounters failures during mailbox synchronization or retry allocation processes, it executes a free operation on pool->stack but fails to set the pointer to NULL afterward. This leaves the pointer in an inconsistent state where subsequent cleanup operations can attempt to free the same memory region twice. The issue is particularly concerning because it occurs during partial initialization when the system is already in an error recovery path, making the double free condition more likely to be triggered and harder to detect through conventional testing methods.
The operational impact of this vulnerability extends beyond simple memory corruption, as it can lead to system crashes, data integrity issues, and potentially provide an attack surface for privilege escalation or denial of service conditions. This type of memory management error aligns with CWE-415: Double Free and CWE-416: Use After Free, both classified under the broader category of memory safety vulnerabilities that are particularly dangerous in kernel space contexts. The vulnerability affects systems running Linux kernel versions including v6.13-rc1 through v7.1-rc3, with the bug being identified through automated analysis tools designed to detect kernel memory management issues.
The fix implemented addresses the root cause by ensuring that pool->stack is set to NULL immediately after the local free operation within otx2_pool_aq_init(), preventing subsequent cleanup paths from attempting to free the same memory region. This approach follows standard defensive programming practices for error handling and resource cleanup, particularly important in kernel drivers where memory safety directly impacts system stability. The mitigation strategy aligns with ATT&CK framework techniques related to privilege escalation and system exploitation through memory corruption vulnerabilities, emphasizing the importance of proper resource management in kernel-level code. The vulnerability was discovered through internal kernel analysis tools, highlighting the need for automated static analysis of kernel code to identify such subtle but critical memory safety issues before they can be exploited in production environments.