CVE-2026-64222

What it actually does

This is a Linux kernel memory-management flaw in the OcteonTX2/CN20K physical function network driver. During an initialization failure path, the driver frees pool->stack but does not clear the pointer; later cleanup code can free the same memory a second time. A successful trigger can corrupt kernel heap state and may lead to kernel crash, denial of service, or potentially local privilege escalation/code execution in kernel context. Exploitation is local, requires low privileges, no user interaction, and appears difficult because it depends on a specific hardware-backed driver path and error conditions during AQ/mailbox or retry-allocation setup.

Why it matters to the business

Organizations running Linux systems with Marvell OcteonTX2 or CN20K networking hardware may face host instability or compromise if a local attacker can trigger the vulnerable driver error path. The most likely operational impact is an unexpected kernel panic or service outage on affected network appliances, edge systems, or servers using this hardware. Although the CVSS score is high, current public risk is moderated by the lack of known exploitation, low EPSS, no KEV listing, and the specialized hardware and timing conditions required.

How an attack unfolds

An attacker first needs local code execution on a Linux system that loads the affected OcteonTX2/CN20K PF driver. The attacker then attempts to influence or repeatedly exercise the driver initialization path so that AQ initialization fails after pool->stack has been allocated and then locally freed. Because the pointer is not nulled, the later unwind path treats the stale pointer as still valid and frees it again through shared cleanup. If the attacker can shape kernel heap state around that double free, they may be able to corrupt allocator metadata or reclaim the freed object in a useful way. In less controlled cases, the system is likely to crash with a kernel oops, panic, KASAN report, or slab allocator corruption message. There are no known public exploit chains or named threat actors associated with this vulnerability at this time.

How to fix it

Upgrade to a Linux kernel version that includes the fix clearing pool->stack to NULL after the local free in the OcteonTX2/CN20K AQ initialization failure paths. Because no fixed versions were provided in the input, obtain the corrected kernel from the relevant Linux distribution, appliance vendor, or kernel stable branch once available, and prioritize systems with Marvell OcteonTX2/CN20K hardware. If immediate patching is not possible, reduce exposure by disabling or unloading the affected driver where not required, preventing untrusted local shell or container access on affected hosts, restricting permissions that allow device reset or driver reload operations, and monitoring for kernel allocator corruption or repeated driver initialization failures. Kernel hardening options such as slab freelist hardening, KASAN in test environments, lockdown, and least-privilege local access controls can reduce exploitability but should not be treated as a complete fix.

How to confirm the fix worked

Confirm the running kernel package or source tree includes the patch that sets pool->stack = NULL immediately after the free in otx2_pool_aq_init() and cn20k_pool_aq_init() error paths. On systems using packaged kernels, verify the vendor advisory or changelog explicitly references the OcteonTX2/CN20K double-free fix. Check whether exposure exists by looking for loaded or available drivers such as octeontx2-pf and by inventorying hardware with Marvell OcteonTX2/CN20K NICs. After remediation, reboot into the fixed kernel and verify the expected kernel version is active. In test environments with matching hardware, exercise driver initialization and failure-handling paths while monitoring dmesg/journalctl for KASAN, slab, double-free, or otx2-related errors.

Typical attack path

1. Gain local low-privileged access to a Linux system using affected OcteonTX2 or CN20K networking hardware and driver support.
2. Confirm the vulnerable driver is present, loaded, or reachable through device initialization/reinitialization paths.
3. Repeatedly trigger driver setup, reset, or error-handling conditions that cause otx2_pool_aq_init() or cn20k_pool_aq_init() to fail after pool->stack is allocated and freed.
4. Cause the shared cleanup path in otx2_sq_aura_pool_init() / otx2_aura_pool_free() to free the stale pool->stack pointer a second time.
5. Attempt to turn the resulting kernel heap corruption into privilege escalation, or cause a kernel crash and denial of service.

How to detect it

Review kernel logs, persistent journal logs, crash dumps, pstore/ramoops records, and monitoring alerts for signs of double free, slab corruption, kernel oops, or panic events involving the OcteonTX2/CN20K driver. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump vmcores, pstore, and EDR telemetry that captures kernel panics or module activity. Focus on systems where octeontx2-pf is loaded or where Marvell OcteonTX2/CN20K hardware is present. Look for repeated initialization failures, mailbox sync failures, AQ initialization failures, or call traces referencing otx2_pool_aq_init(), cn20k_pool_aq_init(), otx2_sq_aura_pool_init(), or otx2_aura_pool_free(). Because there are no known public exploits or actor-specific indicators, detection should be behavior- and artifact-based rather than relying on network IOCs.

• octeontx2-pf
• otx2_pool_aq_init
• cn20k_pool_aq_init
• otx2_sq_aura_pool_init
• otx2_aura_pool_free
• KASAN: double-free
• BUG: KASAN: double-free
• double free or corruption
• kernel BUG at mm/slub.c
• general protection fault
• slab-out-of-bounds
• use-after-free
• kernel panic
• Oops:
• pool->stack
• AQ init failure
• mailbox sync
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /sys/fs/pstore

What your security team should do

• Inventory Linux systems for Marvell OcteonTX2/CN20K hardware and loaded octeontx2-pf driver modules.
• Prioritize patching affected systems that allow local user access, host untrusted workloads, or serve critical network or edge functions.
• Track Linux distribution and appliance-vendor advisories for the first fixed kernel builds, because fixed versions were not supplied in the source data.
• Until patched, restrict local interactive access, container escape opportunities, driver reload/reset permissions, and administrative interfaces that could influence NIC driver initialization.
• Add monitoring for kernel oops, panic, KASAN, slab allocator, and otx2/octeontx2-pf driver errors on potentially affected hosts.
• Treat unexplained crashes on affected hardware as security-relevant until kernel logs and crash dumps rule out allocator corruption around the affected driver paths.
• Do not over-prioritize internet-facing emergency response solely on exploit likelihood: this is not known to be remotely exploitable, is not in KEV, and currently has low EPSS, but it remains important for systems with the affected hardware.