CVE-2026-64121

What it actually does

This is a Linux kernel information disclosure flaw in the IFB virtual network driver. The driver allocates per-queue private statistics storage based on the device TX queue count, but the ethtool statistics path previously iterated using the real RX/TX queue counts. If an IFB device is created with more RX queues than TX queues, an ethtool statistics request can read past the allocated tx_private array and copy adjacent slab memory back to user space. The expected impact is local kernel memory disclosure; the issue is not described as code execution or privilege escalation by itself. Practical exploitation typically requires the ability to create or control IFB devices, which normally requires CAP_NET_ADMIN or equivalent network-administration privileges, though exposure may be higher in containers or delegated network namespaces where that capability is granted.

Why it matters to the business

The primary risk is leakage of sensitive kernel memory to a local user or workload with network-administration privileges. Disclosed memory could contain pointers or adjacent kernel data that help bypass exploit mitigations or support chaining with another local vulnerability. Operationally, the issue is most relevant to Linux systems that use IFB for traffic shaping, ingress redirection, QoS, or virtualized/container networking. EPSS is low, the vulnerability is not currently listed in CISA KEV, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, organizations that grant CAP_NET_ADMIN to containers or untrusted workloads should treat it with higher priority.

How an attack unfolds

An attacker first needs local access to a Linux system or container context with enough network privileges to create or manipulate IFB interfaces. They create an IFB network device with an asymmetric queue configuration, specifically with the RX queue count greater than the TX queue count. They then invoke the ethtool statistics path, for example by requesting interface statistics, which causes the vulnerable kernel code to iterate beyond the allocation used for IFB queue-private data. The kernel copies out-of-bounds slab contents into the statistics response returned to user space. The attacker can repeat the process to collect leaked memory and may use the disclosure to obtain kernel address information or other data useful for a follow-on exploit chain.

How to fix it

Apply a Linux kernel update that includes the IFB fix changing the ethtool statistics accounting to use dev->num_tx_queues consistently. Because no product-specific fixed versions were provided, use the fixed kernel packages from the operating system or appliance vendor and verify the vendor advisory references this issue or the corresponding upstream IFB patch. Where immediate patching is not possible, reduce exposure by removing or blacklisting the ifb module if it is not required, preventing untrusted users or containers from receiving CAP_NET_ADMIN, restricting container network namespace privileges, and limiting use of ethtool/ioctl access from untrusted workloads. Systems that rely on IFB for traffic control should test the patched kernel in staging to confirm traffic shaping and statistics collection continue to function normally.

How to confirm the fix worked

Confirm the running kernel version or vendor package level includes the IFB ethtool statistics fix. On source-built kernels, verify the IFB ethtool stats implementation sizes and walks stats using the allocated TX queue count rather than real RX queue count. Check whether IFB is present with commands such as `lsmod | grep '^ifb'`, `modinfo ifb`, and `ip -d link show type ifb`. To validate exposure safely in a lab, create an IFB interface with asymmetric queues and run `ethtool -S` while monitoring for KASAN or kernel warnings; a patched kernel should return only statistics backed by allocated IFB queue-private entries and should not produce slab-out-of-bounds reports. Avoid running crash-oriented or KASAN reproduction tests on production systems.

Typical attack path

1. Obtain local shell, container execution, or process execution with CAP_NET_ADMIN or equivalent network administration rights.
2. Ensure the IFB module/driver is available or loadable on the system.
3. Create an IFB interface with more RX queues than TX queues, such as one TX queue and multiple RX queues.
4. Request ethtool statistics for the crafted IFB interface.
5. Receive unintended adjacent kernel slab data in the ethtool statistics output.
6. Optionally repeat the leak and use the data to support another local kernel exploit or mitigation bypass.

How to detect it

Retrospective detection is difficult because successful exploitation may only look like legitimate IFB interface creation followed by ethtool statistics collection. Review process execution logs, auditd records, EDR telemetry, shell history, and container runtime logs for creation of IFB devices with asymmetric queue counts and subsequent `ethtool -S` queries. Kernel logs are especially useful on debug, KASAN, or hardened builds: look for slab-out-of-bounds reports involving `ifb_fill_stats_data`, `ifb_get_ethtool_stats`, `__dev_ethtool`, or `dev_ioctl`. In production kernels without KASAN, there may be no explicit crash or warning. Also review privilege assignments for workloads that had CAP_NET_ADMIN and correlate those workloads with execution of `ip link add ... type ifb`, `tc`, or `ethtool` commands. Unexpected IFB interfaces on hosts that do not normally use traffic shaping should be investigated.

• ip link add name ifb
• numtxqueues 1 numrxqueues
• numrxqueues 8 type ifb
• type ifb
• ethtool -S ifb
• ETHTOOL_GSTATS
• ifb_fill_stats_data
• ifb_get_ethtool_stats
• BUG: KASAN: slab-out-of-bounds
• Read of size 8
• __dev_ethtool
• dev_ethtool
• dev_ioctl
• sock_ioctl
• ifb_dev_init
• ifb_ri_tasklet
• ifb_xmit
• ifb_stats64
• /proc/modules
• ifb

What your security team should do

• Patch Linux kernels on systems that use IFB, traffic control, container networking, or delegated network namespaces.
• Prioritize systems where untrusted users, workloads, or containers have CAP_NET_ADMIN, because that capability can make local kernel attack surface reachable.
• Inventory IFB usage across fleets using module inventory, `ip link` output, configuration management, and traffic-control configuration.
• Remove or blacklist the ifb module on systems that do not require ingress shaping or IFB-based traffic control.
• Review container and orchestration policies to avoid granting CAP_NET_ADMIN unless strictly necessary.
• Add audit or EDR detection for unexpected creation of IFB interfaces and suspicious `ethtool -S` usage against IFB devices.
• Monitor kernel logs for KASAN, slab-out-of-bounds, or IFB stack traces that may indicate attempted exploitation or testing.
• If suspicious activity is found, preserve kernel logs, audit logs, process execution telemetry, and container metadata before rebooting or patching.