Look up another CVE · open CVE-2026-80693 in the interactive tracker
CVE-2026-80693
idpf: bound interrupt-vector register fill to the allocated array
Published 2026-08-28 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-80693 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
idpf_get_reg_intr_vecs() fills the caller-allocated reg_vals[] array from the VIRTCHNL2_OP_ALLOC_VECTORS reply in adapter->req_vec_chunks, bounding its inner loop only by the per-chunk num_vectors. The array is sized separately: idpf_intr_reg_init() allocates kzalloc_objs(struct idpf_vec_regs, total_vecs) from caps.num_allocated_vectors and only checks the returned count after the fill. The sum of per-chunk num_vectors is never reconciled against total_vecs, so a reply with a small num_allocated_vectors but chunks summing higher writes past the end of reg_vals[]. Impact: a control plane (a PF or hypervisor device model) that returns a VIRTCHNL2_OP_ALLOC_VECTORS reply whose per-chunk num_vectors sum exceeds num_allocated_vectors writes struct idpf_vec_regs entries past the end of the reg_vals kmalloc allocation (KASAN slab-out-of-bounds write). Bound the fill loop to the array capacity passed in by the callers, mirroring the sibling idpf_vport_get_q_reg(). The existing num_regs < num_vecs check then rejects an undersized reply without the out-of-bounds write happening first.
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/idpf/idpf_dev.c
drivers/net/ethernet/intel/idpf/idpf_vf_dev.c
drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
- What this is
- INTEL ETHERNET DRIVERSMAINTAINERS section matched on drivers/net/ethernet/intel/*/ · intel-wired-lan@lists.osuosl.org · Maintained
- Kernel module
- idpf
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_IDPF|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 idpfPrints 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. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixieMnot built on armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- ?
- not established - no Makefile entry for the affected file
- M
- a module where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_ETHERNET, CONFIG_IDPF, 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
Signals
- Published
- 2026-08-28 (2 months ago)source
- CVSS
- 9.3 critical
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.19%, higher than 8.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 6.7 | 6.18.57 | e299b7d1334e |
| 6.7 | 7.1.8 | 41bb8748124d |
| 6.7 | 7.2 | 9f7007ee9858 |
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 bug is reached only when the idpf driver processes a VIRTCHNL2_OP_ALLOC_VECTORS reply over the PCIe virtchnl/mailbox control queue during idpf_vc_core_init()/idpf_vport_intr_init(); there is no network packet, syscall, or netlink path into idpf_get_reg_intr_vecs().
- AC:LAttack complexity, low
- A malicious control plane fully controls GET_CAPS num_allocated_vectors and per-chunk num_vectors in the ALLOC_VECTORS reply, so the slab out-of-bounds write is deterministic on driver init or hardware-reset re-init without races or attacker-uncontrollable memory layout.
- PR:NPrivileges required, none
- Exploitation requires no credentials on the victim OS; a malicious PF, hypervisor device model, or NIC firmware can inject the crafted virtchnl reply during probe/reset before any local user action, including in cloud VMs where tenants never administer the control plane.
- UI:NUser interaction, none
- No victim interaction is required beyond normal driver bring-up; cloud and server images auto-probe the Intel idpf PF/VF and open netdevs at boot, so the attacker need not wait for a user to mount, click, or manually configure the interface.
- S:CScope, changed
- The attack crosses the SR-IOV/virtio control-plane boundary: a hypervisor or device firmware outside the guest/host kernel trust domain corrupts kernel heap memory inside the idpf driver security authority, matching other virtchnl isolation-breaker CVEs.
- C:HConfidentiality impact, high
- The flaw is a kmalloc slab out-of-bounds write of attacker-influenced struct idpf_vec_regs entries (dyn_ctl_reg, itrn_reg, itrn_index_spacing); such heap corruption can disclose adjacent slab objects and be groomed into an arbitrary kernel read primitive.
- I:HIntegrity impact, high
- Each overfilled entry writes 12 bytes of control-plane-supplied register metadata past reg_vals[], giving a repeatable heap overflow primitive that can corrupt adjacent allocations and be leveraged for control-flow hijack or privilege escalation in the victim kernel.
- A:HAvailability impact, high
- Writing far beyond the reg_vals[] allocation corrupts slab metadata or adjacent kernel objects and can immediately oops/panic the host or guest kernel; hardware-reset recovery re-enters idpf_vc_core_init(), allowing repeated crash or re-exploitation attempts.