CVE-2026-80693 in Linux
Summary
by MITRE • 08/28/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified within the Linux kernel driver for Intel Data Center Interface (idpf) represents a critical memory safety failure rooted in improper input validation and array boundary management. The core issue resides in the idpf_get_reg_intr_vecs function, which is responsible for populating a caller-allocated register value array with data derived from hardware interrupt vector configurations. This operation involves processing replies received via the VIRTCHNL2_OP_ALLOC_VECTORS protocol message sent by the control plane, such as a physical function or hypervisor device model. The driver allocates memory for this buffer based on the total number of vectors reported in the caps.num_allocated_vectors field during initialization. However, when filling this buffer with data from individual chunks within the reply, the code only limits its iteration count using the per-chunk num_vectors value rather than verifying that the cumulative sum does not exceed the pre-allocated array capacity. This architectural oversight creates a scenario where the driver blindly trusts the aggregate size of incoming chunked data without cross-referencing it against the actual memory bounds established during allocation.
The operational impact of this flaw is severe, manifesting as a slab-out-of-bounds write when triggered by a malicious or misconfigured control plane entity. If the reply contains per-chunk num_vectors values that sum to a number greater than caps.num_allocated_vectors, the driver will continue writing struct idpf_vec_regs entries beyond the end of the reg_vals kmalloc allocation. This memory corruption can lead to kernel instability, data leakage, or potentially arbitrary code execution depending on what resides in the adjacent memory regions and how the corrupted data is subsequently utilized by the kernel scheduler or other subsystems that interact with interrupt vectors. The vulnerability effectively allows an attacker controlling the device model or hypervisor interface to corrupt kernel heap memory, bypassing standard safety checks because the validation logic fails to reconcile the sum of individual chunk sizes against the total allocated size before performing write operations.
From a classification perspective, this flaw aligns directly with CWE-787: Out-of-bounds Write, as it involves writing data past the end of an allocated buffer in kernel space. It also relates closely to CWE-20: Improper Input Validation, since the driver fails to adequately validate that the input data from the control plane conforms to expected constraints relative to pre-allocated resources. In terms of attack vectors and tactics, this vulnerability facilitates exploitation through the ATT&CK technique T1548: Abuse Configuration, specifically by manipulating device configuration parameters sent via the virtual channel interface. An adversary with access to the management interface or hypervisor layer could exploit this misconfiguration to achieve privilege escalation or denial of service against the host system running the vulnerable kernel module.
The resolution implemented in the patch addresses these issues by enforcing strict bounds checking on the fill loop within idpf_get_reg_intr_vecs. The fix ensures that the iteration count is bounded by the actual array capacity passed into the function, mirroring the robust validation logic present in the sibling function idpf_vport_get_q_reg. By introducing this constraint, the driver now prevents any write operations from exceeding the allocated memory limits regardless of how many vectors are reported in the chunks. Furthermore, the existing check that verifies if num_regs is less than num_vecs serves as a secondary safeguard to reject undersized or malformed replies before they can cause harm. This dual-layered approach ensures that both overflows and underflows are mitigated, restoring memory safety integrity to the interrupt vector registration process.
To mitigate this vulnerability in environments where kernel updates may not be immediately available, administrators should ensure strict isolation of management interfaces from untrusted networks. Restricting access to the VIRTCHNL2_OP_ALLOC_VECTORS interface to only authorized hypervisor components or trusted physical functions reduces the attack surface significantly. Additionally, enabling Kernel Address Sanitizer (KASAN) in development and testing environments can help detect such out-of-bounds writes early in the software lifecycle before they reach production deployments. For systems already running vulnerable versions, applying the latest kernel patches that include this specific fix is essential to prevent potential exploitation by malicious control plane entities seeking to compromise system stability or gain unauthorized access through memory corruption techniques.