CVE-2026-80693
moderateOut-of-bounds write in Linux kernel idpf interrupt-vector handling
The idpf Ethernet driver in the Linux kernel fails to reconcile two vector counts when processing the VIRTCHNL2_OP_ALLOC_VECTORS reply: the register-array fill loop (idpf_get_reg_intr_vecs) is bounded only by per-chunk num_vectors, while the array is sized from caps.num_allocated_vectors, so a reply whose chunks sum higher writes struct idpf_vec_regs entries past the end of the heap allocation (a KASAN slab-out-of-bounds write). It is triggered when the control plane on the other side of the VIRTCHNL2 interface — the PF or a hypervisor device model — returns an inconsistent reply, which an attacker can cause by compromising the host/hypervisor or the PF-side component. The attacker gains kernel heap memory corruption beyond the allocation, with potential for kernel compromise, information disclosure, or crash (CVSS 9.3, scope changed across the guest/host boundary). Only systems where the idpf driver is actually loaded — machines with VIRTCHNL2-capable Intel Ethernet devices or virtual functions, common in virtualized/cloud deployments — are affected. No public PoC, no CISA KEV listing, and an EPSS of 0.1% indicate no known exploitation at this time.
What to do: Determine whether you are exposed by checking that the idpf module is loaded (lsmod | grep idpf) and that CONFIG_IDPF is enabled in your kernel; if so, plan to apply your distribution's kernel update containing the idpf fix as soon as it is published (no fixed release version is specified in the available data). Since the flaw is triggered from the control-plane side, maintaining host/hypervisor and PF integrity limits the practical attack path.
| Linux kernel (idpf driver, VIRTCHNL2 control path) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: idpf: bound interrupt-vector register fill to the allocated array 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.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.