CVE-2022-48937 in Linux
Zusammenfassung
von VulDB • 29.05.2026
Based on the stack trace provided, here is an analysis of the issue:
### **Summary** This is a **KASAN (Kernel Address Sanitizer)** report indicating a **memory allocation failure** or **invalid memory access** during an `io_uring` operation. Specifically, it occurs in `io_issue_sqe` when trying to allocate memory for an I/O request.
---
### **Key Details from the Stack Trace**
1. **Error Type**: The trace starts with `stack_trace_save` and goes through `____kasan_kmalloc` → `__kasan_kmalloc` → `kmem_cache_alloc_trace`. This indicates that KASAN detected an issue during a `kmalloc` (or slab allocation) call. - Since it’s `kmem_cache_alloc_trace`, it’s likely allocating from a slab cache (e.g., `io_kiocb` or similar). - KASAN typically reports **out-of-bounds**, **use-after-free**, or **invalid allocation** errors. However, the trace here only shows the *allocation* path, not the *faulting access*. This suggests the error might be: - A **failed allocation** that KASAN is flagging due to subsequent invalid access. - Or, the trace is truncated, and the actual fault (e.g., use-after-free) is not shown.
2. **Function Call Path**: - `io_uring_enter` (syscalls) → `io_submit_sqes` → `io_submit_sqe` → `io_queue_sqe` → `io_issue_sqe` - This is the standard path for submitting and issuing I/O requests in `io_uring`.
3. **Critical Function**: `io_issue_sqe` (fs/io_uring.c:4556, 4589, 6828) is where the allocation happens. This function prepares and issues a single I/O request.
4. **Possible Causes**: - **Memory Exhaustion**: The system may be out of memory, causing `kmem_cache_alloc` to fail, and KASAN is catching a subsequent invalid access. - **Use-After-Free**: If the `io_kiocb` structure was freed prematurely, accessing it during `io_issue_sqe` could trigger KASAN. - **Corrupted Slab Cache**: The slab cache itself might be corrupted. - **Bug in io_uring**: A recent kernel bug in `io_uring` could be causing invalid memory operations.
---
### **Recommended Actions**
1. **Check Full KASAN Report**: The trace is truncated. Look for the **full KASAN output**, which usually includes: - The **type of error** (e.g., `BUG: KASAN: use-after-free in io_issue_sqe`). - The **address** that was accessed invalidly. - The **allocation/free stack traces** for the object.
2. **Check System Logs**: Run `dmesg | grep -i kasan` or `dmesg | grep -i io_uring` to see if there are more details.
3. **Reproduce the Issue**: - Identify the workload triggering this (e.g., a specific application using `io_uring`). - Try to reproduce it in a controlled environment.
4. **Update Kernel**: If this is a known bug, check if a newer kernel version fixes it. `io_uring` has had several fixes in recent kernels.
5. **Debugging Steps**: - Enable `CONFIG_KASAN` and `CONFIG_KASAN_INLINE` for more detailed reports. - Use `CONFIG_DEBUG_SLAB` to check for slab corruption. - Add printks or use `ftrace` to trace `io_issue_sqe` calls.
6. **Workaround**: If this is a memory exhaustion issue, consider: - Increasing system memory. - Reducing the number of concurrent `io_uring` requests. - Using `IORING_SETUP_SQPOLL` with caution, as it can consume more memory.
---
### **Conclusion** This is a **KASAN-detected memory error** in `io_uring` during request submission. The exact cause (use-after-free, OOB, etc.) is not fully visible in the truncated trace. Check the full KASAN report and system logs for more details. If this is a production issue, consider updating the kernel or reducing `io_uring` workload as a temporary workaround.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.