CVE-2022-48937 in Linux
Riassunto
di VulDB • 30/06/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 error in the Linux kernel's `io_uring` subsystem. Specifically, it appears to be triggered during submission of I/O requests via `sys_io_uring_enter`.
The stack trace shows execution flowing through: 1. `__x64_sys_io_uring_enter` → System call entry for io_uring. 2. `io_submit_sqes` → Processing submitted queue entries (SQEs). 3. `io_queue_sqe` / `__io_queue_sqe` → Queuing a specific SQE. 4. `io_issue_sqe` → Issuing the I/O operation. 5. **Memory Allocation**: The trace shows calls to `kmem_cache_alloc_trace`, `____kasan_kmalloc`, and `__kasan_slab_alloc`.
### **Key Observations**
1. **KASAN is Active**: The presence of `____kasan_kmalloc` and `__kasan_slab_alloc` confirms that KASAN is enabled in the kernel configuration (`CONFIG_KASAN=y`). This means any memory error (use-after-free, out-of-bounds access, etc.) will be caught immediately.
2. **No Explicit Error Message**: The provided snippet ends with a truncated stack trace and does not include the actual KASAN error message (e.g., "BUG: KASAN: use-after-free in ...", "slab-out-of-bounds", or "double free"). This critical information is usually printed *before* the stack trace.
3. **Allocation Context**: The allocation happens inside `io_issue_sqe` → `__kasan_slab_alloc`. This suggests that during I/O issue, a slab object (likely an `io_kiocb` or related request structure) was allocated. However, KASAN only reports errors *when the memory is accessed incorrectly*, not just when it's allocated. The fact that we see allocation functions in the trace might mean: - The error occurred during access to a previously freed object (use-after-free), and the stack shows where the current operation started. - Or, more likely, **the actual KASAN fault message is missing from this snippet**.
4. **Potential Bug Location**: Since `io_issue_sqe` is in the call chain, if there's a bug, it may involve: - Improper handling of request state (`struct io_kiocb`). - Race conditions during SQE submission or completion. - Memory corruption in data buffers associated with the I/O operation (if `io_uring` is using user-space buffers incorrectly).
### **What’s Missing?** To diagnose this properly, you need: - The **KASAN error header** that precedes the stack trace. It will specify: - Type of bug (`use-after-free`, `heap-buffer-overflow`, etc.). - Address involved. - Which function actually caused the invalid access (not just where allocation happened).
### **Recommendations**
1. **Check Full Kernel Log**: Look at `dmesg` or `/var/log/kern.log` for lines *before* this stack trace. You should see something like: ``` BUG: KASAN: use-after-free in io_issue_sqe+0xabc/0xdef fs/io_uring.c:XXXX Read of size 8 at addr ffff888123456789 by task XXXX ... ```
2. **Reproduce with Minimal Test Case**: If possible, isolate the `io_uring` usage pattern that triggers this (e.g., specific opcodes like `IORING_OP_READ`, `IORING_OP_WRITE`, or linked SQEs).
3. **Check for Known Issues**: Search Linux kernel bugzilla and mailing lists for recent regressions in `fs/io_uring.c`. This subsystem is complex and has had several KASAN-reported bugs, especially around: - Request cancellation (`io_req_cancel`). - Multi-buffer support (`IORING_SETUP_MULTIPOLL` or similar). - User-space buffer registration/unregistration races.
4. **Kernel Version**: Identify your kernel version (e.g., `5.19`, `6.1`, etc.). Many io_uring bugs have been fixed in recent stable releases. Consider upgrading if you're on an older LTS kernel with known issues.
### **Example of What to Look For** If the full log shows: ``` BUG: KASAN: use-after-free in __io_queue_sqe+0x123/0x456 fs/io_uring.c:7143 Read of size 8 at
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.