Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.3",
  "pubDate": "2026-08-28T08:16:54.787Z",
  "pubdate": "2026-08-28T08:16:54.787Z",
  "executiveSummary": "The Linux kernel idpf driver contains a memory safety vulnerability related to improper bounds checking during the processing of interrupt-vector registers.\nThe vulnerability is classified as a slab-out-of-bounds write, which can lead to memory corruption, system instability, or potential arbitrary code execution.\nThe issue affects the idpf_get_reg_intr_vecs() function, where data received from a control plane source, such as a PF or a hypervisor device model, is used to populate an array without verifying that the received volume of data fits within the pre-allocated memory.\nAn attacker controlling the hypervisor or the Physical Function (PF) can craft a malicious VIRTCHNL2_OP_ALLOC_VECTORS response that forces the driver to write beyond the allocated boundary of the reg_vals array.\nThis vulnerability represents a significant risk to system integrity in virtualized environments where the kernel interacts with external device models or privileged control planes.\nExploitation requires the attacker to be in a position to influence the virtchnl communication channel, typically achieved from a compromised or malicious hypervisor/PF.",
  "technicalDetails": "The root cause of the vulnerability lies in an insufficient validation of the correlation between the total number of allocated vectors (num_allocated_vectors) and the cumulative number of vectors provided in per-chunk responses during the VIRTCHNL2_OP_ALLOC_VECTORS operation.\nIn the idpf_get_reg_intr_vecs() function, the kernel allocates an array reg_vals[] based on the initial caps.num_allocated_vectors. However, the logic that processes the incoming data iterates through multiple chunks and fills the reg_vals[] array based solely on the per-chunk num_vectors count.\nBecause the sum of per-chunk num_vectors is never reconciled against the total capacity allocated by idpf_intr_reg_init(), a mismatch occurs when the control plane provides a malicious response where the sum of chunks exceeds the total initial allocation.\nThis results in a KASAN-detectable slab-out-of-bounds write. The attack flow begins with the guest kernel initiating a vector allocation request. The malicious or compromised control plane responds with a crafted VIRTCHNL2_OP_ALLOC_VECTORS message containing an inflated number of vectors per chunk.\nAs the idpf_get_reg_intr_vecs() function processes these chunks, it proceeds to index into the heap-allocated memory of reg_vals[] using an incrementing offset that is not restricted by the physical size of the buffer.\nThe lack of a bounds check prior to the memory write allows the attacker to corrupt adjacent kernel heap objects. Depending on the memory layout, this corruption can overwrite critical kernel data structures, function pointers, or objects that influence kernel flow control.\nSince the vulnerability occurs during the processing of control plane communication, it does not require direct local user-space access; instead, it relies on the trust relationship between the driver and the underlying infrastructure (PF/Hypervisor).\nPost-exploitation impact involves the potential for local privilege escalation or arbitrary kernel code execution, as the overwriting of heap objects can be leveraged to gain control over kernel execution paths by corrupting memory that governs driver or kernel operations."
}