CVE-2022-48653 in Linux
요약
\~에 의해 VulDB • 2026. 05. 24.
Based on the kernel stack trace provided, here is an analysis of the issue:
### **Summary** The system is experiencing a **deadlock or severe contention** on a mutex (`__mutex_lock`) while handling an **IRQ (Interrupt Request)** from an Intel Ethernet adapter (`ice` driver). The interrupt handler triggers a reset sequence (`ice_schedule_reset`), which attempts to delete a device (`device_del`), which in turn tries to acquire a mutex that is already held or contended, causing the CPU to spin/sleep indefinitely in `__mutex_lock`.
---
### **Detailed Breakdown**
1. **Context: IRQ Handler** ``` [ 662.815780] asm_common_interrupt+0x1e/0x40
[ 662.815774] common_interrupt+0xb4/0xd0
[ 662.815770] __common_interrupt+0x62/0x100
[ 662.815766] handle_edge_irq+0x9a/0x1c0
[ 662.815764] handle_irq_event+0x34/0x60
[ 662.815762] handle_irq_event_percpu+0xf/0x40
[ 662.815756] __handle_irq_event_percpu+0x4c/0x180
[ 662.815741] ice_misc_intr+0x21d/0x2d0 [ice]
``` - The interrupt is coming from the **`ice` driver** (Intel Ethernet Controller X710/XL710). - The function `ice_misc_intr` is the interrupt handler.
2. **Event Trigger: IIDC Event** ``` [ 662.815719] ice_send_event_to_aux+0x54/0x70 [ice]
[ 662.815693] irdma_iidc_event_handler.cold.7+0xb6/0xd3 [irdma]
``` - The interrupt handler sends an event to the auxiliary device (`ice_send_event_to_aux`). - This event originates from the **`irdma` driver** (Intel RoCE/iWARP driver), specifically an **IIDC (Internal Inter-Driver Communication)** event. - IIDC is used for communication between the `ice` (PF) and `irdma` (VF/auxiliary) drivers.
3. **Reset Sequence** ``` [ 662.815674] ice_schedule_reset+0x3c/0xd0 [ice]
``` - The event triggers a **reset** of the `ice` device.
4. **Device Deletion & Mutex Contention** ``` [ 662.815639] ice_unplug_aux_dev+0x1a/0x40 [ice]
[ 662.815633] device_del+0x37/0x3d0
[ 662.815603] ? __ibdev_printk+0x76/0xc0 [ib_core]
[ 662.815600] __mutex_lock.isra.11+0x46c/0x490
[ 662.815597] schedule_preempt_disabled+0x14/0x20
[ 662.815595] schedule+0x44/0xc0
[ 662.815588] __schedule+0x798/0x990
``` - During the reset, `ice_unplug_aux_dev` is called. - This calls `device_del` to remove the auxiliary device. - `device_del` attempts to acquire a mutex (likely `dev->mutex` or a related sysfs/kobject lock). - **The mutex is already held**, causing the CPU to sleep in `__mutex_lock` → `schedule` → `__schedule`. - Since this is happening in an **IRQ context** (interrupt handler
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.