CVE-2026-23427 in Linux
Riassunto
di VulDB • 29/06/2026
Based on the KASAN (Kernel Address Sanitizer) trace provided, here is a detailed analysis of the bug:
### **Bug Type** **Use-After-Free (UAF)** Specifically, a kernel memory access to an object that has already been freed.
---
### **Key Details from the Trace**
1. **The Buggy Address**: * `ffff8881056ac000` belongs to the slab cache `kmalloc-1k` (size: 1024 bytes). * The access occurred at an offset of **396 bytes** inside a freed region.
2. **Allocation Trace ("Allocated by task 123")**: * Allocated in function `ksmbd_conn_alloc` (offset +0x44/0x6d0). * Called from `ksmbd_kthread_fn`. * This indicates the object is a **connection structure** (`conn`) for the ksmbd (SMB server) kernel module.
3. **Free Trace ("Freed by task 134")**: * Freed in function `kfree` called from `ksmbd_tcp_disconnect`. * Called from `ksmbd_conn_handler_loop`. * This indicates the connection was explicitly disconnected and its memory freed.
4. **The Problem**: * Task 123 allocated a connection object. * Task 134 (likely another thread handling the same or related connection) called `ksmbd_tcp_disconnect`, which freed that object via `kfree`. * However, some other code path (not fully shown in this snippet but implied by the "buggy address" access later) still holds a pointer to this now-freed memory and attempts to read/write it.
---
### **Root Cause Analysis**
This is a classic race condition or logic error in reference counting/state management within `ksmbd`:
1. **Missing Reference Counting**: The connection object (`conn`) might be freed while another thread still holds an active pointer/reference to it, without proper atomic refcount protection (e.g., missing `kref_get`/`kref_put`). 2. **Use-After-Free in Disconnect Path**: It’s possible that during `ksmbd_tcp_disconnect`, the connection is freed prematurely before all pending operations or callbacks have completed and released their references. 3. **Stale Pointer Dereference**: A thread (possibly Task 123 or another) continues to use a pointer to the `conn` structure after it has been invalidated by `ksmbd_tcp_disconnect`.
---
### **Recommended Fixes**
#### ✅ **Option 1: Add Reference Counting (`kref`)** Ensure that every time a thread starts using the connection, it increments the reference count, and decrements it when done. The object is only freed when the refcount drops to zero.
```c // In ksmbd_conn_alloc(): kref_init(&conn->refs);
// When taking a new reference: static inline void ksmbd_conn_get(struct ksmbd_conn *conn) {
kref_get(&conn->refs); }
// When releasing a reference: void ksmbd_conn_put(struct ksmbd_conn *conn) {
if (kref_put_mutex(&conn->refs, conn_free_func)) return; // Not the last ref, don't free yet. mutex_lock(&ksmbd_global.conn_list_mutex); list_del_rcu(&conn->smb2_conns); mutex_unlock(&ksmbd_global.conn_list_mutex); call_rcu(&conn->rcu_head, conn_free_callback); // Free after RCU grace period }
// In ksmbd_tcp_disconnect(): // Instead of direct kfree(conn), do: ksmbd_conn_put(conn); ```
#### ✅ **Option 2: Ensure No Stale Pointers Are Used** If reference counting is already in place, check for races where a pointer to `conn` is used after it has been removed from the active list but before all users have released their references. Use RCU (`call_rcu`) or synchronize mechanisms to ensure no one accesses freed memory during disconnect.
#### ✅ **Option 3: Check Disconnect Logic** Verify that `ksmbd_tcp_disconnect()` does not free resources while other threads are still actively processing messages on the same connection. Consider deferring cleanup until all pending work is done.
---
### **How to Verify** 1. Rebuild your kernel with KASAN enabled (`CONFIG_KASAN=y`). 2. Reproduce the issue (e.g., by connecting and
VulDB is the best source for vulnerability data and more expert information about this specific topic.