Look up another CVE · open CVE-2026-31505 in the interactive tracker

CVE-2026-31505

iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()

7.8 EPSS 0.2% AV:L

Published 2026-04-22 (6 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-31505 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	vulnerable	6.1.190-1	No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication.
Debian 13trixie	fixedDSA-6238-1 · 2026-04-30 · text	6.12.85-1	Update the kernel and reboot. DSA-6238-1 shipped the fix on 2026-04-30, in 6.12.85-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	6.19.11-1	Update the kernel and reboot. Fixed in 6.19.11-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	6.19.11-1	Update the kernel and reboot. Fixed in 6.19.11-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the value could change in runtime, we should use num_tx_queues instead. Moreover iavf_get_ethtool_stats() uses num_active_queues while iavf_get_sset_count() and iavf_get_stat_strings() use real_num_tx_queues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1]. For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3: Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S) iavf_set_channels() ... iavf_alloc_queues() -> num_active_queues = 8 iavf_schedule_finish_config() iavf_get_sset_count() real_num_tx_queues: 1 -> buffer for 1 queue iavf_get_ethtool_stats() num_active_queues: 8 -> out-of-bounds! iavf_finish_config() -> real_num_tx_queues = 8 Use immutable num_tx_queues in all related functions to avoid the issue. [1] BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800 CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x180 iavf_add_one_ethtool_stat+0x200/0x270 iavf_get_ethtool_stats+0x14c/0x2e0 __dev_ethtool+0x3d0c/0x5830 dev_ethtool+0x12d/0x270 dev_ioctl+0x53c/0xe30 sock_do_ioctl+0x1a9/0x270 sock_ioctl+0x3d4/0x5e0 __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xf3/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... </TASK> The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/net/ethernet/intel/iavf/iavf_ethtool.c

What this is: INTEL ETHERNET DRIVERSMAINTAINERS section matched on drivers/net/ethernet/intel/*/ · intel-wired-lan@lists.osuosl.org · Maintained
Kernel module: iavf

Check it on the machine

grep -wE 'CONFIG_ETHERNET|CONFIG_IAVF|CONFIG_NET_VENDOR_INTEL' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w iavf

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi
forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64

M: a module where it is built at all; some flavours do not build it

Build switches: CONFIG_ETHERNET, CONFIG_IAVF, CONFIG_NET_VENDOR_INTEL
Reads as: all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-04-22 (6 months ago)source
CVSS: 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.18%, higher than 6.5% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: drivers/net

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
5.17	6.12.80	1f931dee5b72
5.17	6.18.21	bb85741d2dc2
5.17	6.19.11	fdf902bf86a8
5.17	7.0	fecacfc95f19

Debian advisories

Advisory	Date	Shipped to	Debian
DSA-6238-1	2026-04-30	trixie 6.12.85-1	tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: The vulnerable path is reached locally through `ioctl(SIOCETHTOOL)` on a socket, specifically `ETHTOOL_GSTATS` calling the iavf ethtool statistics callback. Remote packets may influence counter values but do not directly invoke the vulnerable code.
AC:LAttack complexity, low: The bug is a race between attacker-issued channel reconfiguration and stats retrieval; the attacker can repeatedly run `ethtool -L` and `ethtool -S` to hit the window before `finish_config` updates `real_num_tx_queues`. No rare external condition is required.
PR:LPrivileges required, low: `ETHTOOL_GSTATS` is allowed to any local user, but reliably creating the mismatched queue-count state requires `ETHTOOL_SCHANNELS`, gated by `ns_capable(net->user_ns, CAP_NET_ADMIN)`. In plausible delegated VF/container netns deployments this is a low namespace privilege rather than real init-namespace root.
UI:NUser interaction, none: No victim action is required when the attacker has the needed local namespace capability; the attacker can issue both ethtool operations directly. The vulnerable stats read itself is synchronous from the attacker’s ioctl.
S:UScope, unchanged: The corruption occurs inside the same kernel security authority as the vulnerable network driver. This is standard kernel memory corruption/privilege escalation, not a VM escape or IOMMU boundary bypass.
C:HConfidentiality impact, high: The flaw is an out-of-bounds kernel write in a vmalloc-backed stats buffer, which is memory corruption that can plausibly be leveraged during exploitation for information disclosure. Under the required conservative rule, this is High.
I:HIntegrity impact, high: The vulnerable function writes attacker-influenced u64 statistics past the allocated buffer when queue counts diverge. Out-of-bounds kernel writes are treated as high integrity impact because they can corrupt kernel memory and potentially enable code execution.
A:HAvailability impact, high: The reported failure is a KASAN vmalloc-out-of-bounds write in kernel context, and the same corruption can oops or panic the kernel. The trigger can be repeated by local ethtool calls.