CVE-2022-48840 is a critical vulnerability affecting certain Linux kernel versions when using the Virtual Function (VF) Networking Drivers, especially *iavf*. This bug leads to hang-ups or deadlocks during system reboot or shutdown, leaving servers unresponsive, and particularly impacting setups with SR-IOV and the Intel *iavf* driver.

In this post, I’ll explain how the bug works, why it happens, and how it was fixed—with clear explanations, original links, and code examples. This is exclusive and accessible—no deep kernel knowledge needed.

Background: Virtual Functions and the iavf Driver

- SR-IOV (Single Root I/O Virtualization) enables one physical NIC (network interface card) to appear as several “virtual” devices (VFs).

The iavf driver manages these VFs.

- Underlying PF (Physical Function) drivers, such as ice (for Intel E800 adapters), manage full device resources.

Source of the Problem

A commit (974578017fc1) was added to avoid VFs being removed before initialization is complete. To do this, developers placed a wait loop at the start of iavf_remove():

/* Wait for port initialization */
while (!adapter->port_initialized) {
    usleep_range(100, 200);
}

But here’s the catch: During system shutdown or reboot, this wait loop could cause a permanent hang—effectively deadlocking the reboot process.

1. iavf_shutdown() detaches the device, makes it down, and sets its state to __IAVF_REMOVE.

2. Later, during parent driver shutdown (example: ice_shutdown()), sriov_disable() indirectly calls iavf_remove().
3. Now, iavf_remove() sees the adapter state is __IAVF_REMOVE, but the code BEFORE this fix continues waiting forever because port initialization won’t finish—the state machine is stuck.

The result: Your server never completes the reboot, hanging indefinitely.

If you hit SysRq during the hang, you see output like

[52625.996732] Call Trace:
[52625.999187]  __schedule+x2d1/x830
[52626.007400]  schedule+x35/xa
[52626.020046]  usleep_range+x5b/x80
[52626.023540]  iavf_remove+x63/x5b [iavf]
[52626.027645]  pci_device_remove+x3b/xc
[52626.031572]  device_release_driver_internal+x103/x1f
[52626.036805]  pci_stop_bus_device+x72/xa
[52626.040904]  pci_stop_and_remove_bus_device+xe/x20
[52626.045870]  pci_iov_remove_virtfn+xba/x120
[52626.050232]  sriov_disable+x2f/xe
[52626.053813]  ice_free_vfs+x7c/x340 [ice]
[52626.057946]  ice_remove+x220/x240 [ice]
[52626.061967]  ice_shutdown+x16/x50 [ice]
[52626.065987]  pci_device_shutdown+x34/x60
[52626.070086]  device_shutdown+x165/x1c5
[52626.074011]  kernel_restart+xe/x30
[52626.077593]  __do_sys_reboot+x1d2/x210

How to Reproduce

Lab setup:

Reboot the system.

You’ll see the hang like above if the buggy kernel is in use.

The Fix: Intelligent State Checking

The Solution:
Instead of always running the wait loop, check the adapter state at the beginning of iavf_remove(). If the VF is already in remove state (e.g., being shut down), skip the wait and cleanup gracefully.

Patched code snippet

int iavf_remove(struct pci_dev *pdev)
{
    struct iavf_adapter *adapter = pci_get_drvdata(pdev);

    /* Skip everything if we're already in __IAVF_REMOVE */
    if (adapter->state == __IAVF_REMOVE)
        return ;

    /* Previous code with the wait loop */
    while (!adapter->port_initialized) {
        usleep_range(100, 200);
    }

    // ... continue with normal remove steps ...
}

End result:
- On reboot/shutdown, iavf_remove() exits early if the VF is already being removed.

- Upstream Linux Kernel Commit Fix
- Original iavf remove wait regression commit
- iavf Driver on kernel.org
- Red Hat Bugzilla Bug 2157813 (upstream reporting)
- LKML Patch Discussion

Exploit Potential

While this bug doesn’t allow for code execution or privilege escalation, it is a denial-of-service vector:

- Remote or local users triggering a reboot/shutdown could hang production servers.
- Especially impactful in cloud/nfv environments using SR-IOV and Intel adapters.

Note: No traditional “exploit” code since this is about making the system hang via (legit) system operations.

How to Fix It

- If you compile your own kernel: Apply the patch from upstream, or upgrade to a kernel version that includes it.
- On RHEL, Ubuntu, others: Install the latest security/bugfix kernel updates from your vendor.

`sh

strings /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/intel/iavf/iavf.ko | grep __IAVF_REMOVE
`
Should show the logic in place.

---

## Summary

- CVE-2022-48840 made Linux servers with Intel SR-IOV VF networking hang on shutdown/reboot.
- It’s traced to an overzealous wait loop, fixed by adding a simple state check.
- A clean patch is available and now in upstream Linux.
- Update kernels to stay safe, avoid downtime and reboot drama!

Share this if your colleagues or sysadmins run Intel networking on Linux!

---

Have questions or need help with your environment? Drop a comment below!

Timeline

Published on: 07/16/2024 13:15:11 UTC
Last modified on: 07/17/2024 20:37:49 UTC