CVE-2026-80817 in Linux
Sumário
de VulDB • 04/09/2026
Based on the kernel crash dump provided, here is an analysis of the issue.
### **Summary** This is a **Kernel NULL Pointer Dereference** (or invalid memory access) occurring in the `iommufd` subsystem, specifically within the function `iommufd_ioas_change_process`. The faulting address (`CR2`) is `0x00000000000000c0`, which indicates an attempt to dereference a pointer at offset `0xc0` (192 bytes) from NULL.
---
### **Key Details**
#### 1. **Faulting Instruction & Location** - **Function**: `iommufd_ioas_change_process+0x419/0xd50` - **File**: `drivers/iommu/iommufd/ioas.c:538` - **RIP (Instruction Pointer)**: `0010:iommufd_ioas_change_process+0x419`
#### 2. **Faulting Address** - **CR2**: `00000000000000c0` - This means the CPU tried to access memory at address `0xc0`. Since base is NULL, this implies a structure member offset of `0xc0` was accessed on a NULL pointer.
#### 3. **Register State Analysis** - **RAX**: `ffff8880186d5328` (Valid kernel memory) - **RCX**: `00007f4aec1a82bd` (User-space address, likely a pointer passed from userspace via syscall) - **RDI**: `00000000000000c0` → **This is the critical register.** - In x86_64 System V ABI, `RDI` holds the first argument to functions. - The value `0xc0` in `RDI` matches the faulting address (`CR2`). This strongly suggests that a pointer expected by the kernel was actually an integer offset or invalid user-space pointer, and when dereferenced (or used as an index/offset), it caused the crash at `NULL + 0xc0`.
#### 4. **Call Trace Context** - The trace shows: ``` RIP: 0010:iommufd_ioas_change_process+0x419/0xd50 drivers/iommu/iommufd/ioas.c:538 Code: ... <8b> ad c0 00 00 00 bf 01 00 00 00 89 ee e8 85 ef cb fd 83 fd 01 74 ``` - The instruction `movl $0x1, %r12d` (or similar) and subsequent operations suggest the code is handling process context changes for an IOMMU Address Space (`ioas`).
---
### **Root Cause Analysis**
The function `iommufd_ioas_change_process` is responsible for changing the owning process of an IOMMU address space. The crash occurs because:
1. A pointer expected to be valid (likely a struct like `struct iommufd_ctx`, `struct file *`, or internal ioas data) was **NULL** or invalid. 2. Specifically, at offset `0xc0` within that structure, the code attempted to read/write memory. 3. Since the base pointer was NULL, accessing `[RAX + 0xc0]` (or similar) resulted in a fault at address `0xc0`.
#### Likely Scenario: - A userspace application passed an invalid or uninitialized file descriptor/context handle via the `iommufd` ioctl interface. - The kernel failed to validate this input properly before dereferencing it. - Alternatively, there is a race condition where the context was freed while still being accessed during process change operations.
---
### **Recommended Actions**
#### For Developers/Kernel Maintainers: 1. **Check Input Validation**: Review `iommufd_ioas_change_process` in `drivers/iommu/iommufd/ioas.c`. Ensure that all pointers derived from userspace (especially those passed via ioctl arguments) are validated using `get_user()`, `copy_from_user()`, or proper file descriptor resolution (`fdget()`). 2. **Null Pointer Checks**: Add explicit NULL checks before dereferencing any pointer at offset `0xc0` within the relevant structure. 3. **Race Condition Audit**: Verify that no other thread can free the context while this function is executing. Use reference counting (`kref_get/put
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.