CVE-2026-23017

What it actually does

NULL pointer dereference in idpf_vc_event_task after failed init_task during driver load leaves vports and netdevs uninitialized, so a later reset causes the service task to dereference invalid memory.

Why it matters to the business

Kernel crashes on systems using the affected Intel idpf driver, leading to unplanned downtime and potential data loss during resets or reloads; widespread in Linux distributions shipping recent kernels.

How an attack unfolds

An attacker with local access triggers a driver load failure (for example by forcing firmware rejection of CREATE_VPORT), then induces a reset; the service task then crashes the kernel while accessing uninitialized resources.

How to fix it

Upgrade the Linux kernel to commit a514c374edcd33581cdcccf8faa7cc606a600319 or later; rebuild and reboot with the patched driver. If immediate patching is not possible, avoid resets after any observed init_task failure.

How to confirm the fix worked

Confirm the running kernel contains commit a514c374edcd33581cdcccf8faa7cc606a600319; attempt a driver load that previously failed and verify no subsequent reset produces a NULL dereference in idpf_vc_event_task.

Typical attack path

1. Gain local access to a system with the vulnerable idpf driver
2. Cause init_task to fail during module load or probe
3. Trigger a device or driver reset
4. Observe kernel NULL pointer dereference and panic in idpf_vc_event_task

How to detect it

Review kernel logs for idpf init_task failures followed by NULL pointer dereference in idpf_vc_event_task or idpf_vc_core_init; correlate with device reset events and workqueue activity.

What your security team should do

• Prioritize kernel update to the fixed commit on all systems using idpf hardware
• Monitor for idpf init failures in dmesg and schedule maintenance windows before resets
• Test the patched driver in a staging environment before broad deployment