KernelScan.io

CRITICAL Introduced in 6.7

idpf IntrVec OOB Write

CVE-2026-80693

CVSS 9.3 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

KernelScan AI7.1HIGH

01

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.

02

Engine v0.6.0

Risk summary

An Intel idpf Ethernet adapter control plane (PF driver or hypervisor device model) can return a crafted VIRTCHNL2_OP_ALLOC_VECTORS reply whose per-chunk vector count exceeds the allocated array size, causing the guest VF driver to write past the end of a kmalloc buffer. This results in kernel heap corruption that can lead to denial of service or potentially code execution. The issue affects systems running the idpf VF driver against a malicious or compromised control plane.

Affecteddrivers/net/ethernet/intel/idpf/idpf_virtchnl.c (idpf Intel Ethernet driver)

Vulnerability analysis

The idpf interrupt-vector register fill routine copies entries from a control-plane reply into a caller-allocated array without checking that the total number of entries being copied fits within the array's capacity. The array is sized from one field in the reply while the copy loop is bounded by a different per-chunk count, so a reply where the chunk sums exceed the allocated vector count writes past the end of the heap buffer. The fix passes the array capacity into the fill routine and stops the copy when that limit is reached, so an oversized reply is rejected before any out-of-bounds write occurs. The vulnerable path is reached when the idpf VF driver processes a VIRTCHNL2_OP_ALLOC_VECTORS reply from its control plane — a physical function driver or hypervisor device model — so an attacker would need to control or compromise the control plane on the other side of the virtualization boundary.

03

BranchIntroducedFixed inPatch commit
6.126.76.12.114a6447b6a9678
6.186.76.18.57e299b7d1334e
7.16.77.1.841bb8748124d
mainline6.77.29f7007ee9858

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Affected — no CIP fix yet (latest 6.12.112-cip33)