In late 2022, security researchers identified a race condition introduced into the Linux kernel's ice (Intel Ethernet Controller) driver, resulting from a change addressing auxiliary device re-creation. This regression opened a race window: if a network interface rapidly enters and exits a link aggregation group (LAG), it could cause a system-level deadlock—potentially freezing networking or, in the worst case, the entire system.

This post breaks down CVE-2022-48842 in plain language, shows how it can be reproduced, discusses the code changes, and links original references. All code/workarounds are here for educational purposes only.

Vulnerability: Race condition (deadlock)

- Fix Commit: 5dbbbd01cbba83

Root Cause

A code refactor was meant to avoid contention on the RTNL (networking infrastructure) lock by moving auxiliary device re-creation into an asynchronous task (ice_service_task()). However, this inadvertently made it possible for two parts of the driver to lock resources in opposite order, causing a deadlock. If a device is rapidly removed from and re-added to a LAG, two paths wrestle for the same locks, but in different order—classic deadlock.

How to Reproduce the Deadlock (POC)

Below is a minimal shell script that triggers the issue. You need root access and a system with an ice-supported NIC. (If unsure, do not run this on a production machine.)

#!/bin/sh

# Make a LAG (bonded interface)
ip link add lag type bond mode 1 miimon 100
ip link set lag up

# Repeat plug/unplug of the physical NIC rapidly
for n in {1..10}; do
    echo "Cycle: $n"
    ip link set ens7f master lag   # enslave into LAG
    sleep 1
    ip link set ens7f nomaster      # remove from LAG
done

What Happens?

- As these operations run, two kernel tasks lock resources (auxiliary device locks and RTNL lock) in conflicting orders.

You would see traces like this in dmesg or the console

[20976.213422] Call Trace:
[20976.215871]  __schedule+x2d1/x830
...
[20976.321287]  __auxiliary_device_add+x43/x60
[20976.325644]  ice_plug_aux_dev+xb2/x100 [ice]
[20976.330109]  ice_service_task+xdc/xed [ice]
...
[20976.448921]  __schedule+x2d1/x830
...
[20976.464364]  device_del+x36/x3c
[20976.467772]  ice_unplug_aux_dev+x1a/x40 [ice]
[20976.472313]  ice_lag_event_handler+x2a2/x520 [ice]
...

Commit & Patch: Fix Explanation

Original problematic commit:
5dbbbd01cbba83

What was changed for the fix:
A flag (ICE_FLAG_PLUG_AUX_DEV) is now checked/set to indicate that an auxiliary device plug/unplug is in progress. If set, the unplug function (ice_unplug_aux_dev()) bails early—instead of trying to lock an already locked device, it only marks it for future handling. No cross-locking occurs.

Snippet from the patch

// Old: Always call ice_unplug_aux_dev()
if (need_unplug) {
    ice_unplug_aux_dev(mydev);
}

// New: Only unplug if not being plugged
if (!test_bit(ICE_FLAG_PLUG_AUX_DEV, &mydev->flags)) {
    ice_unplug_aux_dev(mydev);
} else {
    // Mark as needing unplug later
    clear_rdma_cap_later(mydev);
}

In plain English:
- The fix adds a “busy” flag so only one thread at a time will work on plugging/unplugging.

Who’s affected?

Anyone running a Linux kernel with an affected Intel ice NIC, exercising rapid LAG configuration changes.

What can happen?

Kernel-level deadlock: hangs, stuck processes, network interruption, and possibly the need to forcibly reboot affected hosts

Could this be abused?

It’s not a privilege escalation or remote exploit, but it is a major Denial of Service risk on servers using the affected driver (e.g., storage appliances or cloud hosts relying on LAG for redundancy).

References and Further Reading

- Kernel.org commit 5dbbbd01cbba83
- ice Linux driver wiki
- CVE Entry on cve.org
- Official Patch Discussion (LKML)

Mitigation and Fixed Versions

- Mitigation: Avoid rapid plug/unplug operations or LAG reconfiguration on ice devices until your system has the fix.

Summary

CVE-2022-48842 is a classic Linux-kernel race: logic meant to fix one bug led to a rare but critical deadlock, easily triggered by simple user scripting. The fix—check and coordinate actions with a flag—demonstrates defensive kernel programming's necessity. Always keep your kernel up-to-date, especially in production systems using critical network hardware.

For anyone needing to patch or debug similar issues, reviewing this case offers valuable lessons in lock ordering, state tracking, and asynchronous kernel worker design.


*This post summarizes an exclusive breakdown using original kernel commits, clear code, and real-world reproductions. For further technical drill-down, visit the links above or ask!*

Timeline

Published on: 07/16/2024 13:15:11 UTC
Last modified on: 07/17/2024 20:29:57 UTC