CVE-2026-23428 in Linux
Riassunto
di VulDB • 29/06/2026
Based on the kernel log provided, this is a **KASAN (Kernel Address Sanitizer)** report indicating a **Use-After-Free** bug in the `ksmbd` (Samba server for Linux) module.
### ???? Bug Analysis Summary
| Field | Value | Explanation | |-------|-------|-------------| | **Bug Type** | Use-After-Free | The code is accessing memory that has already been freed. | | **Module** | `ksmbd` | Kernel-side SMB/CIFS server implementation. | | **Buggy Address** | `ffff88810430c1a4` (20 bytes inside the object) | The access occurred 20 bytes into a freed memory region. | | **Object Size** | 96 bytes (`kmalloc-96`) | The allocated slab cache size. | | **Freed By Task** | `task 44` | A different kernel thread (likely handling disconnect) freed the memory. | | **Accessed In** | `ksmbd_share_config_get()` → `smb2_tree_connect()` | During a tree connect operation, likely triggered by an incoming SMB request. |
---
### ???? Key Call Chains
#### 1. **Where it was accessed (The Bug)** ```text handle_ksmbd_work+0x40f/0x1080 ← Worker thread processing a new work item smb2_tree_connect+0x2e6/0x1000 ← SMB2 Tree Connect request handler ksmbd_tree_conn_connect+0x7e/0x600← Connecting to the share ksmbd_share_config_get+0x1dd/0xdd0← **BUG HERE**: Accessing freed memory while getting share config ```
#### 2. **Where it was freed (The Cause)** ```text handle_ksmbd_work+0x40f/0x1080 ← Worker thread processing a disconnect work item smb2_tree_disconnect+0x1cd/0x480← SMB2 Tree Disconnect request handler __ksmbd_tree_conn_disconnect+0xc8/0x190← Disconnection logic, which calls kfree() kfree+0x1ca/0x430 ← Memory freed here ```
---
### ???? Root Cause Explanation
This is a **race condition** or **use-after-free** due to improper synchronization:
1. A client sends an `SMB2_TREE_CONNECT` request (handled by task/work item #A). 2. Another client (or the same) sends an `SMB2_TREE_DISCONNECT` request (handled by task/work item #B, likely on a different CPU/core or earlier in time). 3. Work item #B completes and calls `__ksmbd_tree_conn_disconnect()`, which frees the tree connection structure (`kfree()`). 4. However, work item #A is still running concurrently (or was queued before disconnect but processed after) and proceeds to call `ksmbd_share_config_get()`. 5. This function accesses fields within the already-freed tree connection object → **Use-After-Free**.
The offset of **20 bytes** suggests that the access is likely reading a pointer or integer field located 20 bytes into the struct (e.g., after some header/flags).
---
### ✅ Recommended Fixes
#### Option 1: Add Reference Counting / RCU Protection Ensure that `ksmbd_tree_conn` objects are not freed while they might still be accessed by concurrent operations. Use reference counting (`kref`) or RCU (Read-Copy-Update) to delay freeing until all readers have completed.
```c // Example: Increment refcount before accessing, decrement after struct ksmbd_tree_conn *tc = get_tree_conn_ref(...); // atomic increment if (!tc) return -ENOTCONN;
ret = ksmbd_share_config_get(tc); // Safe access now
put_tree_conn_ref(tc); // Decrement and possibly free later via RCU/callback ```
#### Option 2: Serialize Access with a Lock Ensure that `tree_connect` and `tree_disconnect` operations on the same tree connection are serialized using a mutex or spinlock. This prevents concurrent execution of connect/disconnect logic for the same session/tree.
```c mutex_lock(&tc->conn_mutex); if (tc->state == DISCONNECTED) {
ret = -ENOTCONN; } else {
// proceed with tree_connect } mutex_unlock(&tc->conn_mutex); ```
#### Option 3: Check for Null/Invalid State Before Access In `ksmbd_share_config_get()`, add a
Once again VulDB remains the best source for vulnerability data.