CVE-2022-48941

What it actually does

Race condition in ice driver allows concurrent VF reset and removal operations without proper locking via VF cfg_lock, resulting in DMA memory use-after-free, device queue shutdown races, and kernel memory corruption or panics.

Why it matters to the business

Unpatched Linux systems using Intel ice NICs with SR-IOV may experience sudden kernel crashes and reboots during VF lifecycle operations, leading to unplanned downtime for virtualized networking workloads.

How an attack unfolds

Local attacker or automated script rapidly creates, resets, and removes VFs while the PF driver processes virtchnl messages; the missing cfg_lock allows the remove path to free resources while a reset or message handler still references them, triggering the corruption.

How to fix it

Update the Linux kernel to a version containing commit 3c805fce07c9dbc47d8a9129c7c5458025951957 (or equivalent stable backport) which protects reset and removal flows with the VF cfg_lock and reverts the prior ICE_VF_DEINIT_IN_PROGRESS flag approach.

How to confirm the fix worked

Verify the running kernel contains commit 3c805fce07c9 or later equivalent; exercise VF creation/reset/removal loops under load and confirm absence of ice-related panics or corruption; review dmesg for resolved concurrency warnings.

Typical attack path

1. Obtain local access or execute privileged code on a system with ice driver and SR-IOV enabled
2. Create multiple VFs and bring them up
3. Trigger concurrent VF reset and .remove operations in rapid succession
4. Cause the PF driver to process messages or reset tasks after partial teardown has begun
5. Trigger kernel panic or memory corruption

How to detect it

Search kernel logs and crash dumps for ice driver messages mentioning VF teardown, virtchnl handling during remove, or concurrent reset/remove; inspect for panics with stack traces involving ice_vf or cfg_lock paths.

What your security team should do

• Prioritize kernel upgrade on all systems exposing ice driver with SR-IOV
• Schedule staged rollout beginning with highest-availability workloads
• Monitor kernel logs for ice VF teardown errors until patches are applied
• Disable SR-IOV temporarily on non-production systems if upgrade is delayed