CVE-2026-23013: Linux Kernel Use-After-Free Vulnerability

CVE-2026-23013 Overview

A Use-After-Free vulnerability has been discovered in the Linux kernel's Octeon EP VF network driver. The flaw exists in the octep_vf_request_irqs() function where MSI-X queue IRQs are requested with dev_id set to ioq_vector. When request_irq() fails partially, the rollback loop incorrectly calls free_irq() with dev_id set to oct instead of the original ioq_vector, causing a mismatch that may leave the irqaction registered.

This improper IRQ cleanup can keep interrupt handlers alive while ioq_vector is later freed during unwind/teardown operations, leading to a use-after-free condition or system crash when an interrupt fires.

Critical Impact
This vulnerability can lead to kernel crashes, denial of service, or potential code execution through use-after-free exploitation when the affected network driver encounters IRQ allocation failures.

Affected Products

Linux kernel with Octeon EP VF network driver (octeon_ep_vf)
Systems using Marvell/Cavium Octeon network adapters in virtual function mode
Kernel configurations with CONFIG_OCTEON_EP_VF enabled

Discovery Timeline

2026-01-25 - CVE CVE-2026-23013 published to NVD
2026-01-26 - Last updated in NVD database

Technical Details for CVE-2026-23013

Vulnerability Analysis

The vulnerability resides in the error handling path of the octep_vf_request_irqs() function within the Octeon EP VF driver. When allocating MSI-X interrupts for network queue vectors, the driver passes ioq_vector as the dev_id parameter to request_irq(). This dev_id serves as a unique identifier that must be consistent between request_irq() and free_irq() calls.

If any request_irq() call fails during the allocation loop, the driver attempts to roll back previously allocated IRQs. However, the rollback code incorrectly uses oct (the main device structure) as the dev_id parameter instead of the ioq_vector that was originally used. Since free_irq() relies on dev_id matching to properly identify and remove the IRQ handler, this mismatch causes the cleanup to fail silently, leaving IRQ handlers registered.

The consequence is particularly severe: when the driver unwinds and frees the ioq_vector structures, the still-registered interrupt handlers maintain stale pointers. Any subsequent interrupt delivery triggers a use-after-free condition as the handler attempts to access the freed ioq_vector memory, potentially causing kernel memory corruption or a system panic.

Root Cause

The root cause is an inconsistent use of the dev_id parameter between the IRQ request and free operations in the error handling path. The original code passed ioq_vector to request_irq() but erroneously passed oct to free_irq() during rollback, violating the Linux kernel's IRQ management contract that requires matching dev_id values.

Attack Vector

The attack vector for this vulnerability is local and requires the ability to trigger conditions that cause request_irq() to fail during driver initialization or reconfiguration. This could potentially be achieved through:

Resource exhaustion attacks depleting available IRQ vectors
Manipulating system state to cause IRQ allocation failures
Triggering driver reinitialization under constrained conditions

Once triggered, an attacker who can control timing or inject interrupts could potentially exploit the use-after-free condition for privilege escalation or arbitrary code execution within kernel context.

The vulnerability mechanism involves the following sequence:

Driver calls octep_vf_request_irqs() to allocate MSI-X interrupts
Multiple request_irq() calls succeed, registering handlers with ioq_vector as dev_id
A subsequent request_irq() fails, triggering the error path
Rollback loop calls free_irq() with incorrect dev_id (oct instead of ioq_vector)
IRQ handlers remain registered but ioq_vector structures are freed
Interrupt delivery causes use-after-free when handlers access freed memory

For technical implementation details, see the kernel git commit fix.

Detection Methods for CVE-2026-23013

Indicators of Compromise

Kernel panic messages referencing octeon_ep_vf driver or octep_vf functions
KASAN (Kernel Address Sanitizer) reports showing use-after-free in IRQ handler context
Unexpected system crashes during network driver initialization or teardown
Kernel log entries showing IRQ allocation failures followed by use-after-free warnings

Detection Strategies

Enable CONFIG_KASAN in kernel builds to detect use-after-free conditions at runtime
Monitor kernel logs for messages related to octep_vf_request_irqs failures
Implement kernel tracing on IRQ allocation and deallocation for the octeon_ep_vf driver
Deploy runtime kernel integrity monitoring to detect memory corruption patterns

Monitoring Recommendations

Configure alerting on kernel panic events involving network driver subsystems
Establish baseline monitoring for IRQ allocation patterns on systems with Octeon adapters
Enable kernel crash dump collection for forensic analysis of exploitation attempts
Monitor for unusual patterns of driver reinitialization or network interface flapping

How to Mitigate CVE-2026-23013

Immediate Actions Required

Update to a patched Linux kernel version containing the fix commit
Avoid using Octeon EP VF network driver on untrusted or multi-tenant systems until patched
If unable to patch immediately, consider disabling the octeon_ep_vf module
Review system configurations for alternative network driver options if applicable

Patch Information

The fix ensures that the error path in octep_vf_request_irqs() uses the correct ioq_vector as the dev_id parameter when calling free_irq() during rollback, maintaining consistency with the original request_irq() calls.

The following kernel commits address this vulnerability:

Workarounds

Blacklist the octeon_ep_vf kernel module if not required for system operation
Use physical function drivers instead of virtual function drivers where possible
Implement kernel lockdown policies to reduce attack surface
Apply kernel hardening options such as CONFIG_HARDENED_USERCOPY and stack protection

bash

# Disable octeon_ep_vf module if not required
echo "blacklist octeon_ep_vf" >> /etc/modprobe.d/blacklist-octeon.conf
update-initramfs -u

# Verify module is not loaded
lsmod | grep octeon_ep_vf