CVE-2021-47201

What it actually does

Use-after-free condition in the iavf driver caused by calling iavf_free_queues before iavf_free_q_vectors, which clears num_active_queues that the latter function still needs, resulting in a kernel panic on subsequent interface bring-up.

Why it matters to the business

Interface disable followed by re-enable after PF communication restores can crash the system, causing downtime for virtual functions and any workloads relying on the affected network adapter.

How an attack unfolds

An attacker with local access triggers the race by disabling the VF interface, waiting for PF communication to restore, then bringing the interface back up; the incorrect free order dereferences freed memory and panics the kernel.

How to fix it

Update the Linux kernel to a version containing the fix that swaps the order of iavf_free_queues and iavf_free_q_vectors calls in iavf_disable_vf; for the listed package apply commit 22ce6b047aa63f0c8a75e68182dbd9dd5dd99eff.

How to confirm the fix worked

Confirm the patched kernel or commit is installed, then exercise VF disable/enable cycles while monitoring for panics; review dmesg for the resolved ordering of free calls.

Typical attack path

1. Obtain local access to a system using the vulnerable iavf driver
2. Disable the VF interface
3. Restore PF communication
4. Re-enable the interface to trigger the panic

How to detect it

Search kernel logs for iavf_disable_vf panics occurring after interface disable and subsequent re-enable; correlate with PF communication restore events.

What your security team should do

• Prioritize kernel updates on systems exposing iavf VFs
• Monitor for interface disable/enable patterns that precede crashes
• Apply the exact commit listed for any downstream packages