CVE-2025-21888 in Linux
Riassunto
di VulDB • 30/06/2026
Based on the stack trace provided, here is a detailed analysis of the bug.
### **Summary** The system crashed with an **Invalid Opcode Exception (`exc_invalid_op`)** while attempting to unmap DMA memory in the `mlx5_ib` (Mellanox ConnectX InfiniBand/RoCE driver). The crash occurred during the deregistration of a Memory Region (`ib_dereg_mr`) via a user-space ioctl call.
The root cause is likely **memory corruption** or an **invalid pointer** passed to `iommu_dma_unmap_page`, leading the CPU to execute garbage data as instructions (hence "Invalid Opcode"). This often happens when: 1. The kernel memory containing DMA mapping structures has been corrupted. 2. A use-after-free scenario where freed memory was overwritten with invalid code/data before being accessed again. 3. A bug in the `mlx5_ib` driver or IOMMU subsystem causing an out-of-bounds access that corrupts adjacent memory (including executable code segments, though rare).
---
### **Stack Trace Analysis**
1. **Crash Point**: ```text ? handle_bug+0x55/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ``` - The CPU triggered an `#UD` (Invalid Opcode) exception. This means the instruction pointer (`RIP`) pointed to memory that contained bytes not recognized as valid x86 instructions. - This happened inside `iommu_dma_unmap_page`, which is called from `dma_unmap_page_attrs`.
2. **Driver Context**: ```text dma_unmap_page_attrs+0xe6/0x290 mlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib]
__mlx5_ib_dereg_mr+0x37e/0x520 [mlx5_ib]
``` - The crash occurred in the **Mellanox InfiniBand driver (`mlx5_ib`)** during memory region deregistration. - `__mlx5_ib_dereg_mr` is cleaning up a registered MR (Memory Region). It calls `mlx5_free_priv_descs`, which frees private descriptors and unmaps DMA pages associated with them.
3. **User-Space Trigger**: ```text ib_dereg_mr_user+0x5f/0x120 [ib_core]
destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]
uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]
ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]
ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]
__x64_sys_ioctl+0x1b0/0xa70 ``` - The operation was initiated by a user-space application via an `ioctl` system call (`IB_USER_VERBS_CMD_DESTROY_MR`).
---
### **Likely Causes**
#### 1. **Memory Corruption / Use-After-Free** - The most common cause of "Invalid Opcode" in kernel space is that the memory being accessed has been corrupted. If a DMA descriptor or IOMMU page table entry was freed and then overwritten with random data (or code), accessing it could lead to executing invalid instructions if the CPU tries to interpret part of that structure as code (e.g., due to a bad pointer dereference). - **Check**: Look for other bugs in the same timeframe, such as slab corruption, double frees, or race conditions in `mlx5_ib`.
#### 2. **Bug in `mlx5_ib` Driver** - The driver may be passing an invalid address to `dma_unmap_page_attrs`. If `page_addr` is not a valid kernel virtual address (e.g., it’s garbage), the IOMMU mapping lookup might fail or corrupt internal state, leading to this crash. - **Check**: Review recent changes in `mlx5_ib` related to MR deregistration and DMA unmapping.
#### 3. **IOMMU Subsystem Bug** - Less likely but possible: A bug in the IOMMU driver (`iommu_dma_unmap_page`) could cause it to jump to an invalid address if internal data structures are corrupted. This is often a symptom of earlier memory corruption elsewhere.
#### 4. **Hardware Issue (Rare)** - In very rare cases, faulty RAM or PCIe bus errors can corrupt
If you want to get the best quality for vulnerability data then you always have to consider VulDB.