CVE-2022-48653 in Linux
Riassunto
di VulDB • 19/06/2026
Based on the kernel stack trace provided, here is an analysis of the issue:
### **Summary** The system is experiencing a **deadlock or severe contention** involving the `ice` (Intel Ethernet) driver and the `irdma` (Intel RoCE/iWARP) driver. The CPU is stuck trying to acquire a mutex (`__mutex_lock`) while handling an interrupt, which eventually leads to a timeout or scheduler issue, causing the system to hang or become unresponsive.
---
### **Detailed Breakdown of the Stack Trace**
1. **The Root Cause: Mutex Contention** ``` [ 662.815600] __mutex_lock.isra.11+0x46c/0x490
``` The kernel is blocked in `__mutex_lock`. This means a thread is trying to acquire a lock that is already held by another thread (possibly in a different context, like an interrupt handler or another CPU).
2. **The Context: Device Removal/Reset** ``` [ 662.815633] device_del+0x37/0x3d0
[ 662.815639] ice_unplug_aux_dev+0x1a/0x40 [ice]
[ 662.815674] ice_schedule_reset+0x3c/0xd0 [ice]
``` The `ice` driver is attempting to **unplug a device** (`ice_unplug_aux_dev`) and schedule a reset (`ice_schedule_reset`). This is likely triggered by a hardware error, link down event, or a reset request.
3. **The Trigger: RDMA/iWARP Event** ``` [ 662.815693] irdma_iidc_event_handler.cold.7+0xb6/0xd3 [irdma]
[ 662.815719] ice_send_event_to_aux+0x54/0x70 [ice]
``` The `irdma` driver (Intel RDMA/Mellanox-compatible RoCE/iWARP) is handling an event (`irdma_iidc_event_handler`). It sends this event to the `ice` auxiliary device via `ice_send_event_to_aux`. This suggests that the RDMA subsystem is notifying the Ethernet driver about a state change (e.g., link failure, reset needed).
4. **The Interrupt Context** ``` [ 662.815741] ice_misc_intr+0x21d/0x2d0 [ice]
[ 662.815756] __handle_irq_event_percpu+0x4c/0x180
... [ 662.815780] asm_common_interrupt+0x1e/0x40
``` The entire sequence is happening inside an **interrupt handler** (`ice_misc_intr`). Interrupt handlers should be fast and non-blocking. However, here it is trying to acquire a mutex (`__mutex_lock`), which is **illegal or highly discouraged** in interrupt context if the lock might be held in process context. This is a classic cause of deadlocks.
5. **The Result: Scheduler Hang** ``` [ 662.815588] __schedule+0x798/0x990
[ 662.815595] schedule+0x44/0xc0
``` The kernel is stuck in the scheduler, waiting for the mutex to become available. Since the lock holder is likely in a process context that is also blocked (or the system is otherwise hung), this results in a **soft lockup** or **hard lockup**.
6. **The Final State: CPU Idle** ``` [ 662.815785] RIP: 0010:cpuidle_enter_state+0xd6/0x380
``` The CPU is trying to enter an idle state (`cpuidle_enter_state`), but it cannot because it is stuck in the interrupt handler trying to acquire the lock. This indicates the system is completely frozen.
---
### **Likely Causes**
1. **Deadlock between Process Context and Interrupt Context:** - A process (e.g., `ethtool`, `ip link`, or a user-space RDMA
If you want to get best quality of vulnerability data, you may have to visit VulDB.