CVE-2026-64121

In the Linux kernel, the following vulnerability has been resolved:

net: ifb: report ethtool stats over num_tx_queues

ifb_dev_init() allocates dp->tx_private to dev->num_tx_queues entries via kzalloc_objs(*txp, dev->num_tx_queues). Both IFB per-queue RX and TX stats live in those entries: ifb_xmit() updates txp->rx_stats using the skb queue mapping, ifb_ri_tasklet() updates txp->tx_stats, and ifb_stats64() aggregates both over dev->num_tx_queues.

The ethtool stats callbacks instead size and walk the per-queue stats with dev->real_num_rx_queues and dev->real_num_tx_queues. With an asymmetric device where the RX queue count exceeds the TX queue count, for example:

ip link add name ifb10 numtxqueues 1 numrxqueues 8 type ifb
ethtool -S ifb10

ifb_get_ethtool_stats() indexes past the tx_private allocation and copies adjacent slab data through ETHTOOL_GSTATS.

Use dev->num_tx_queues consistently for the stats strings, the stats count, and the stats data walks. This reports one RX stats group and one TX stats group for each backing ifb_q_private entry, which is the queue set IFB can actually populate.

Reproduced under UML+KASAN at v7.1-rc2:

BUG: KASAN: slab-out-of-bounds in ifb_fill_stats_data+0x3c/0xae Read of size 8 at addr 0000000062dbd228 by task ethtool/36 ifb_fill_stats_data+0x3c/0xae ifb_get_ethtool_stats+0xc0/0x129 __dev_ethtool+0x1ca5/0x363c dev_ethtool+0x123/0x1b3 dev_ioctl+0x56c/0x744 sock_do_ioctl+0x15f/0x1b2 sock_ioctl+0x4d5/0x50a sys_ioctl+0xd8b/0xde9

With the patch applied, the same UML+KASAN repro is silent and ethtool -S ifb10 reports only the stats backed by the single allocated tx_private entry.

Weakness

The product reads data past the end, or before the beginning, of the intended buffer.

Affected Software

Potential Mitigations

• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
• To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/540.html

References

• https://git.kernel.org/stable/c/16bd798cb6d8337d7c3eea1adc412f31b5181d5b
• https://git.kernel.org/stable/c/2638e1773904d7aa8f24c6e7fda2ed7d69df6fa4
• https://git.kernel.org/stable/c/301a554e458e2f5ec47f2c336a7cb03b877f9fd6
• https://git.kernel.org/stable/c/5db89c99566fc4728cc92e941d8e1975711e24b5
• https://git.kernel.org/stable/c/6afdb8113cb007f9332f59a9b7fd45731b8a9de5
• https://git.kernel.org/stable/c/f8a5a76b4a683043c6eff2a060bcaa17f9316ad5