GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel i40e: wrong VF state check lets a VF obtain resources outside the valid state

CVSS 8.8CVE-2025-39969Kernel, userspace & hypervisorcurated

Impact

The Intel X710/XL710 (i40e) PF driver used I40E_VF_STATE_ACTIVE to decide whether a virtual function may obtain resources, but that is not the only state in which a VF is active, so the check did not actually gate the request; the fix keys off I40E_VF_STATE_RESOURCES_LOADED, which is set only in i40e_vc_get_vf_resources_msg and cleared on reset. On a GPU node with SR-IOV VFs handed to tenant VMs or pods, this means a tenant VF can request resources at a point in the lifecycle the driver did not expect - NVD scores it as a local, scope-changing issue with high impact across the board. The upstream commit message does not spell out the memory-safety consequence, so treat the severity as the host driver entering an unexpected state rather than a demonstrated host takeover. Nodes without i40e SR-IOV are unaffected.

Who can reach it

Local - a tenant in control of an i40e virtual function, issuing virtchnl get-resources requests to the host PF driver. Needs control of the guest or pod holding the VF; no host credentials.

What to do

Update the host kernel to a stable release containing the I40E_VF_STATE_RESOURCES_LOADED check (commits in the record) and reboot the affected nodes - reloading i40e tears down the NIC and all its VFs, so plan a drain and reboot. Interim control is to stop exposing i40e VFs to untrusted guests.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.