CVE-2024-42291

What it actually does

A malicious VF driver can bypass the existing 128-filter software limit in iavf and request an unbounded number of FDIR filters, exhausting hardware resources that are shared across VFs on the same PF.

Why it matters to the business

In virtualized or cloud environments using SR-IOV, one compromised or malicious guest can degrade or deny network filtering services to other guests sharing the same physical adapter, leading to service disruption and potential loss of availability for dependent workloads.

How an attack unfolds

An attacker with control of a VF driver crafts repeated requests to add FDIR filters beyond the intended software cap. Because no corresponding per-VF hardware limit existed in the ice driver, the requests succeed until shared resources are exhausted, starving other VFs of filter capacity. The fix introduces an explicit per-VF counter and enforcement in the PF driver.

How to fix it

Upgrade the Linux kernel to a version containing commit e81b674ead8e2172b2a69e7b45e079239ace4dbc or later. Rebuild and redeploy any custom kernel packages or distributions that incorporate the ice driver. Where immediate patching is not possible, restrict untrusted VF assignment or disable FDIR offload for affected interfaces.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit or a backport that adds per-VF FDIR accounting. Exercise VF filter allocation from multiple guests and verify that requests are rejected once the per-VF limit is reached rather than allowing unbounded consumption.

Typical attack path

1. Obtain or compromise a VF assigned to a target ice PF
2. Load or modify an iavf driver to issue FDIR filter addition requests in a tight loop
3. Continue requests until the PF-level resource pool is depleted
4. Observe or trigger failures in other VFs that can no longer install required filters

How to detect it

Review kernel logs on the PF host for repeated ice driver messages related to FDIR filter allocation failures or resource exhaustion. Correlate guest VF activity with sudden loss of flow-director rules on peer VFs. No public exploit artifacts or specific log strings have been widely published for this issue.

What your security team should do

• Prioritize kernel updates on any system exposing ice-based SR-IOV to untrusted guests
• Audit VF-to-PF assignments and apply least-privilege isolation where possible
• Monitor vendor advisories for distribution-specific backports of the fix