CVE-2023-54037 in Linux
Riassunto
di VulDB • 29/06/2026
Based on the kernel oops log provided, here is a detailed analysis of the crash:
### **Summary** * **Crash Type:** Kernel Page Fault (Oops) in `ice` driver. * **Triggering Function:** `ice_get_ringparam()` within the Intel Ice network driver (`[ice]`).
* **Context:** The fault occurred while handling a netlink request to get ring parameters for an Ethernet device, likely triggered by user-space tools like `ethtool`.
---
### **Detailed Analysis**
#### 1. **The Faulting Instruction** ```text ? ice_get_ringparam+0x22/0x50 [ice]
``` * The crash happened inside the function `ice_get_ringparam` at offset `0x22`. * This function is part of the Intel Ice (E810/E82C) network driver. It retrieves ring buffer parameters for ethtool queries.
#### 2. **Call Trace Breakdown** The call trace shows how we got to this point: ```text rings_prepare_data+0x62/0x80 <-- Helper function preparing data for ring params ethnl_default_doit+0xe2/0x350 <-- Generic netlink handler for ethtool requests genl_family_rcv_msg_doit... <-- Netlink message processing netlink_rcv_skb+0x58/0x110 <-- Receive socket buffer from user space __sys_sendto+0x126/0x170 <-- System call entry (user-space triggered) ``` * A user-space process called `sendto()` on a netlink socket. * This was likely an `ethtool` command querying ring parameters (`ETHTOOL_MSG_RINGS_GET`). * The kernel routed this to the Ice driver’s handler, which crashed when trying to access memory.
#### 3. **Register State & Fault Address** ```text DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ... ? __die+0x23/0x70 ... ? page_fault_oops+0x171/0x4e0 ... ? exc_page_fault+0x7f/0x180 ... ? asm_exc_page_fault+0x26/0x30 ``` * **Page Fault:** The CPU raised a page fault exception (`exc_page_fault`). This means the driver tried to read/write from an invalid or unmapped kernel virtual address. * **DR7 = 0x400**: Indicates that debug registers were not actively setting breakpoints at the time of the crash (the `B` bits are clear). The fault was a standard memory access violation, not triggered by hardware debugging.
#### 4. **Root Cause Hypothesis** The most likely causes for this specific oops in `ice_get_ringparam()` include:
1. **Null Pointer Dereference:** The driver may be accessing a pointer (e.g., to the net device structure, ring info, or hardware context) that is NULL because: * The network interface was down/uninitialized when queried. * The PCI device was removed while ethtool was querying it.
2. **Use-After-Free:** If the driver’s internal data structures were freed (e.g., during unload or reset) but still referenced by a pending netlink request, accessing them would cause a page fault.
3. **Hardware State Mismatch:** The Ice driver interacts closely with hardware registers and DMA rings. If the device is in an unexpected state (e.g., firmware error, incomplete initialization), dereferencing ring descriptors could point to invalid memory.
4. **Concurrency Issue:** A race condition between: * Netlink request handling (`ice_get_ringparam`) * Device reset/unload routines that free or modify the same data structures.
---
### **Recommended Actions**
#### ✅ For Users/Admins: 1. **Update Driver/Firmware:** Ensure you are using the latest version of the `ice` driver and Intel E810/E82C firmware. This bug may have been fixed in newer kernel versions or driver releases. ```bash # Check current ice module version modinfo ice | grep version
# Update via your distro's package manager (e.g., linux-firmware, intel-ice-driver) ```
2. **Avoid Querying During Reset/Unload:**
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.