CVE-2025-68213

What it actually does

Null pointer dereference in idpf_remove when vport_config[i] is NULL during driver unload after failed vport or VF initialization, resulting in kernel panic.

Why it matters to the business

Unexpected system crashes and downtime in Linux environments using idpf network drivers, especially those relying on SR-IOV VF provisioning, increasing operational risk until patched.

How an attack unfolds

An attacker with local privileges triggers a vport initialization failure (for example during VF creation), then forces driver removal or SR-IOV disable; the missing NULL check in idpf_remove causes the kernel to dereference an invalid pointer and panic.

How to fix it

Upgrade the Linux kernel to a fixed version such as 6.12.60 or apply commit a0e1c9bc1c9fe735978150ad075616a728073bc7; Chainguard users should update gitlab-pages-fips-17.8 to 17.8.2-r0.

How to confirm the fix worked

Confirm the running kernel contains the fix, then reproduce a failed VF creation followed by driver removal and verify no NULL dereference occurs.

Typical attack path

1. Cause vport_config initialization to fail inside the idpf driver
2. Invoke sriov_disable or driver removal path
3. Trigger idpf_remove without the added NULL guard on vport_config
4. Kernel dereferences NULL pointer and panics

How to detect it

Search kernel logs for BUG: kernel NULL pointer dereference mentioning idpf_remove and the call trace through pci_iov_remove_virtfn or sriov_disable.

• BUG: kernel NULL pointer dereference, address: 0000000000000028
• RIP: idpf_remove+0x11c/0x200 [idpf]
• idpf_sriov_configure+0x58/0x140 [idpf]

What your security team should do

• Apply the kernel update to all affected systems without delay
• Restrict unprivileged access to SR-IOV configuration interfaces
• Enable kernel panic logging and monitoring for idpf-related oops
• Test driver unload paths in staging environments that simulate init failures