CVE-2026-64121

CVE CVE-2026-64121EUVD EUVD-2026-45806Published 2026-07-19T15:40:19.000Z

What the advisory describes

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.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

Linux — Linux a21ee5b2fcb8d6d3973446c5039e966c4cfe40d1 <5db89c99566fc4728cc92e941d8e1975711e24b5; a21ee5b2fcb8d6d3973446c5039e966c4cfe40d1 <f8a5a76b4a683043c6eff2a060bcaa17f9316ad5; a21ee5b2fcb8d6d3973446c5039e966c4cfe40d1 <2638e1773904d7aa8f24c6e7fda2ed7d69df6fa4; patch: 7.0.11; 5.17; a21ee5b2fcb8d6d3973446c5039e966c4cfe40d1 <6afdb8113cb007f9332f59a9b7fd45731b8a9de5; patch: 0; patch: 6.6.142; a21ee5b2fcb8d6d3973446c5039e966c4cfe40d1 <16bd798cb6d8337d7c3eea1adc412f31b5181d5b; patch: 6.12.92; patch: 6.1.175; a21ee5b2fcb8d6d3973446c5039e966c4cfe40d1 <301a554e458e2f5ec47f2c336a7cb03b877f9fd6; patch: 7.1; patch: 6.18.34

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

Linux — Linux

Does this concern one of your customers?

This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.

Try it for 28 days

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.