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:

1. Driver calls octep_vf_request_irqs() to allocate MSI-X interrupts
2. Multiple request_irq() calls succeed, registering handlers with ioq_vector as dev_id
3. A subsequent request_irq() fails, triggering the error path
4. Rollback loop calls free_irq() with incorrect dev_id (oct instead of ioq_vector)
5. IRQ handlers remain registered but ioq_vector structures are freed
6. 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:

• Kernel Git Commit Fix
• Kernel Git Commit Update
• Kernel Git Commit Change

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

# 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