CVE-2026-64225

What it actually does

This is a Linux kernel memory-safety flaw in the OcteonTX2 AF CGX network driver. The driver uses a firmware-provided RESP_LINKSTAT_SPEED value as an index into the cgx_speed_mbps array, which has 13 elements, while the response value can be 0 through 15. Values 13, 14, or 15 cause an out-of-bounds array read. In practical terms, the most likely impact is incorrect link-speed handling, kernel warning/crash, or denial of service on systems using the affected Marvell/Cavium OcteonTX2 networking hardware/driver path. There is no public indication of weaponized exploitation, and the EPSS score is low.

Why it matters to the business

Organizations running affected Linux kernels on systems that use OcteonTX2/CGX networking could experience network instability, degraded connectivity, or system crashes if the vulnerable code path is triggered. Because this is kernel-level code, failures can affect host availability and dependent services. The current exploitation likelihood appears low: it is not in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score.

How an attack unfolds

An attacker would need a way to influence or trigger the CGX link-status response consumed by the OcteonTX2 AF driver. When the driver processes a RESP_LINKSTAT_SPEED value outside the expected cgx_speed_mbps table range, specifically 13 through 15, it reads beyond the array boundary. Depending on kernel build, memory layout, and runtime conditions, this may result in incorrect speed reporting, a kernel fault, or broader system instability. This is hardware- and driver-dependent, so exploitation is expected to be limited to systems using the affected OcteonTX2 CGX functionality rather than generic Linux hosts.

How to fix it

Upgrade to a Linux kernel version that includes the OcteonTX2 AF CGX bounds-check fix for cgx_speed_mbps indexing. If vendor kernels are used, apply the relevant distribution, appliance, or hardware-vendor kernel update rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by avoiding use of the affected OcteonTX2 CGX driver path where feasible, disabling unused interfaces, limiting administrative access to hardware/network management planes, and scheduling reboots or maintenance windows to apply kernel updates promptly.

How to confirm the fix worked

Confirm exposure by checking whether the system is running a kernel that contains the OcteonTX2 AF CGX driver and whether OcteonTX2/CGX hardware is present or the driver is loaded. Validate remediation by confirming the installed kernel package includes the patch adding a bounds check before indexing cgx_speed_mbps and by verifying the system has booted into the fixed kernel. Operationally, monitor for absence of recurring kernel messages, link-state instability, or crashes associated with the octeontx2-af/cgx driver after patching.

Typical attack path

1. Identify a Linux system using the affected OcteonTX2 AF CGX networking driver/hardware path.
2. Trigger or wait for a CGX link-status event that returns an out-of-range RESP_LINKSTAT_SPEED value.
3. Cause the driver to use the out-of-range value as an index into cgx_speed_mbps.
4. Induce kernel misbehavior such as incorrect link-state handling, kernel warning, crash, or denial of service.
5. Leverage resulting service disruption or host instability to impact availability.

How to detect it

Review kernel and system logs for signs that the OcteonTX2 AF CGX driver encountered abnormal link-status handling or caused kernel instability. Useful sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore data, and network interface monitoring records. Look for messages referencing octeontx2-af, CGX, link-status processing, kernel oops/panic, array bounds or UBSAN/KASAN reports, and unexplained network interface flapping on affected hardware. Because no public exploit artifacts are known and this flaw is triggered in kernel driver logic, detection is likely to be behavioral rather than based on a unique payload or network signature.

• octeontx2-af
• CGX
• cgx_speed_mbps
• RESP_LINKSTAT_SPEED
• index out of bounds
• array-index-out-of-bounds
• UBSAN: array-index-out-of-bounds
• KASAN
• kernel BUG
• kernel Oops
• Kernel panic
• link state changed
• NIC Link is Down
• NIC Link is Up

What your security team should do

• Prioritize patching Linux systems that use Marvell/Cavium OcteonTX2 networking hardware or load the octeontx2-af driver.
• Ask Linux distribution, appliance, or hardware vendors for the fixed kernel build if exact fixed package versions are not listed in advisory data.
• Inventory hosts for loaded OcteonTX2-related kernel modules and CGX-capable hardware to avoid broad, unnecessary emergency patching of unaffected systems.
• Monitor kernel logs for octeontx2-af, CGX, link-status, out-of-bounds, kernel oops, panic, or interface flap events.
• Treat this primarily as an availability-risk vulnerability unless new exploit evidence emerges.
• Track threat intelligence for any change in exploit maturity, KEV status, or EPSS trend.