CVE-2026-80693

What it actually does

Out-of-bounds write in idpf_get_reg_intr_vecs() when a VIRTCHNL2_OP_ALLOC_VECTORS reply supplies per-chunk num_vectors summing higher than the kzalloc-sized reg_vals[] array derived from caps.num_allocated_vectors, causing KASAN slab-out-of-bounds write of struct idpf_vec_regs entries.

Why it matters to the business

Local kernel memory corruption on systems using the idpf driver can lead to privilege escalation, system crashes, or denial of service; 32 days post-disclosure with stable low exploit probability still requires prompt kernel updates to avoid exposure in virtualized or high-privilege network environments.

How an attack unfolds

An attacker with local access crafts or influences a malicious control-plane response (PF or hypervisor) returning an oversized VIRTCHNL2_OP_ALLOC_VECTORS reply; idpf_intr_reg_init() allocates based on the smaller num_allocated_vectors while the fill loop trusts the chunk sums, writing past the buffer and corrupting adjacent kernel slabs.

How to fix it

Update to a Linux kernel containing the bound-fill fix that mirrors the logic in idpf_vport_get_q_reg() and rejects undersized replies before the write; apply the vendor-supplied kernel package for the affected distribution as soon as available.

How to confirm the fix worked

Confirm the presence of the upstream patch that adds an explicit bounds check against the caller-supplied array capacity in idpf_get_reg_intr_vecs(); recompile or reinstall the kernel and verify the driver no longer trusts un-reconciled chunk counts from the virtchnl reply.

Typical attack path

1. Obtain local execution on a Linux system with the vulnerable idpf driver loaded
2. Trigger or emulate a VIRTCHNL2_OP_ALLOC_VECTORS reply whose per-chunk vector counts exceed the allocated total
3. idpf_get_reg_intr_vecs() performs unbounded write into the undersized reg_vals[] allocation
4. Kernel slab metadata or adjacent objects are corrupted, enabling further exploitation or crash

How to detect it

Review kernel logs for KASAN reports citing slab-out-of-bounds write involving idpf_vec_regs or idpf_get_reg_intr_vecs; inspect virtchnl reply handling paths and any unusual vector allocation counts returned to the idpf driver.

What your security team should do

• Prioritize kernel updates on any host exposing the idpf driver within the next patching cycle
• Monitor upstream stable and distribution security feeds for the corrected idpf.c changes
• Restrict untrusted control-plane or hypervisor components that could supply crafted virtchnl replies
• Test the updated kernel in a staging environment before broad deployment to avoid boot or networking regressions