CVE-2026-64113

What it actually does

This is a use-after-free flaw in the Linux kernel ixgbevf virtual-function network driver. During receive processing, ixgbevf_clean_rx_irq() may free an skb when pruning VEPA multicast frames whose source MAC address matches the VF’s own MAC address, but it can continue processing with the stale skb pointer on the next loop iteration. The driver can then dereference freed skb metadata in NAPI softirq context, potentially causing kernel memory corruption, kernel panic, denial of service, information exposure, or, in a worst case, kernel-level code execution. Practical exploitation is hardware-, driver-, and traffic-path-dependent; no public exploit maturity is indicated, and the EPSS score is currently low, but the CVSS severity is critical because the vulnerable path is reachable through network packet processing without authentication when the affected driver and topology are present.

Why it matters to the business

Systems using Intel 10GbE virtual functions through the ixgbevf Linux kernel driver may be exposed to remotely triggered kernel crashes or compromise from malicious network traffic, especially in virtualized or multi-tenant network environments where untrusted parties can send Layer 2 traffic toward affected VFs. The most likely operational impact is instability, packet loss, host or guest outages, and service interruption; the worst-case impact is privileged compromise of the affected Linux system. Because this is a kernel vulnerability, successful exploitation can affect the confidentiality, integrity, and availability of workloads relying on the impacted network interface. It is not currently listed in CISA KEV and no ransomware use is indicated, but the issue should still be prioritized for systems with exposed ixgbevf interfaces.

How an attack unfolds

An attacker first needs network reachability to a system using the ixgbevf driver, typically by being on the same Layer 2 segment, virtual switch, or otherwise able to deliver crafted frames to the affected virtual function. The attacker sends traffic that exercises the VEPA multicast source-pruning logic, specifically frames that cause the driver to free an skb because the frame source MAC matches the VF’s own MAC address. Because the freed skb pointer is not reset before the loop continues, subsequent receive-descriptor processing can treat the stale pointer as valid and call ixgbevf_add_rx_frag() on freed memory. This dereferences skb shared-info metadata after free in softirq context. Depending on heap state and timing, exploitation may result in a kernel oops, panic, network driver failure, or potentially controlled memory corruption. Public information indicates the bug was identified by static analysis and confirmed with a KASAN reproduction of the code pattern rather than full hardware end-to-end exploitation, so real-world exploit reliability is unknown.

How to fix it

Apply a Linux kernel update that includes the ixgbevf fix which clears the skb pointer before continuing after VEPA multicast source pruning. No exact fixed package versions were provided in the input, so remediation should be tracked through the relevant Linux distribution kernel advisories and upstream stable kernel releases that mention the ixgbevf use-after-free fix for VEPA multicast source pruning. Reboot into the fixed kernel after installation; merely installing a kernel package is not sufficient if the system continues running the old kernel. If immediate patching is not possible, reduce exposure by disabling or unloading ixgbevf where feasible, moving affected workloads away from ixgbevf-backed SR-IOV virtual functions, restricting untrusted Layer 2 adjacency, applying strict virtual switch and port security controls, enabling anti-spoofing/MAC filtering where supported, and monitoring for kernel oops/panic events involving ixgbevf_clean_rx_irq. Systems not loading or using the ixgbevf driver are not exposed to this specific driver flaw.

How to confirm the fix worked

Confirm exposure by checking whether the ixgbevf module is loaded and bound to an active interface, for example with lsmod, modinfo ixgbevf, ethtool -i <interface>, lspci -k, and driver symlinks under /sys/class/net/*/device/driver. Confirm remediation by verifying the running kernel version is the updated vendor-fixed version, the system has rebooted into that kernel, and the ixgbevf driver build corresponds to the fixed kernel package. Review distribution security advisories or kernel changelogs for wording such as "ixgbevf: fix use-after-free in VEPA multicast source pruning". Where safe test infrastructure exists, validation can include stress-testing multicast/VEPA traffic while watching dmesg, journalctl -k, crash dumps, and KASAN-enabled test kernels for absence of slab-use-after-free reports in ixgbevf receive paths. Do not perform exploit-style validation on production systems because the expected failure mode may be a kernel crash.

Typical attack path

1. Identify a Linux system using the ixgbevf virtual-function network driver, commonly in a virtualized Intel 82599/X520/X540-class SR-IOV deployment.
2. Gain the ability to send Layer 2 or otherwise delivered network frames to the affected VF interface.
3. Craft or generate multicast/VEPA-related traffic where the source MAC condition triggers pruning of frames matching the VF’s own MAC address.
4. Cause ixgbevf_clean_rx_irq() to free the skb and continue without clearing the stale pointer.
5. Trigger subsequent receive processing that reuses the stale skb pointer and dereferences freed skb metadata.
6. Achieve a kernel crash or network service disruption; with more advanced heap manipulation, attempt to turn the use-after-free into broader kernel memory corruption.

How to detect it

To determine whether this was already exploited, review kernel logs, persistent journal entries, hypervisor or guest console logs, crash dumps, and monitoring alerts for kernel memory errors or panics involving ixgbevf receive processing. Primary log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore artifacts, hypervisor management logs for guest resets, and EDR telemetry that records kernel panics or unexpected reboots. Look for KASAN reports naming slab-use-after-free, ixgbevf_clean_rx_irq, ixgbevf_add_rx_frag, skb_shinfo, NAPI, net_rx_action, or dev_kfree_skb_irq. Also investigate unexplained network-driver resets, interface flaps, packet loss, and host reboots correlated with bursts of multicast or unusual Layer 2 traffic. Packet capture evidence, if available, should be examined for frames delivered to affected VFs where the source MAC appears to match the VF’s own MAC, especially multicast/VEPA-related traffic. There are no known public threat actors or ransomware campaigns associated with this issue in the provided data, so detection should focus on behavioral and forensic artifacts rather than known attacker infrastructure.

• ixgbevf_clean_rx_irq
• ixgbevf_add_rx_frag
• skb_shinfo
• dev_kfree_skb_irq
• BUG: KASAN: slab-use-after-free
• slab-use-after-free in ixgbevf
• use-after-free in ixgbevf
• NAPI softirq
• net_rx_action
• kernel panic - not syncing
• Oops:
• Call Trace:
• ixgbevf
• /var/log/kern.log
• /var/log/messages
• /var/crash
• vmcore

What your security team should do

• Inventory Linux systems and virtualized workloads using the ixgbevf driver, prioritizing internet-facing, shared, multi-tenant, or untrusted Layer 2 network segments.
• Patch affected systems through the appropriate distribution kernel update channel and reboot into the fixed kernel.
• If patching is delayed, migrate high-risk workloads away from ixgbevf-backed SR-IOV interfaces or disable the affected VF interfaces where operationally possible.
• Restrict untrusted Layer 2 access to affected VFs using virtual switch controls, MAC anti-spoofing, port isolation, VLAN segmentation, and network admission controls.
• Increase monitoring for kernel oops, panic, KASAN, soft lockup, or unexpected reboot events involving ixgbevf, ixgbevf_clean_rx_irq, ixgbevf_add_rx_frag, skb_shinfo, or NAPI receive processing.
• Review host crash dumps and kernel logs from the period since publication for signs of unexplained ixgbevf receive-path crashes.
• Track vendor advisories for exact fixed kernel package versions because no per-package fixed versions were provided in the input.