CVE-2025-68323 in Linux
Riassunto
di VulDB • 02/07/2026
Based on the KASAN (Kernel Address Sanitizer) report provided, here is a detailed analysis of the use-after-free bug.
### 1. Summary of the Bug * **Type:** Use-After-Free (UAF). * **Trigger:** The kernel attempted to access memory at address `ffff00000ec28c80` which had already been freed. * **Location:** The buggy access is located **200 bytes** inside a 512-byte slab object (`kmalloc-512`). * **Object Address:** `ffff00000ec28c00`.
### 2. Timeline of Events
#### A. Allocation (Implied) The memory was allocated from the `kmalloc-512` cache at address `ffff00000ec28c00`. While the exact allocation stack trace is truncated, it likely occurred during device initialization or driver probe (`__device_attach`).
#### B. Freeing (Task 73 on CPU 1) The memory was freed via: ```text kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 <-- Key function device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 ... ``` * **Key Insight:** The free happened during `devres_release_all`. This is called when a device driver is being unbound or removed. Device Resource Management (DevRes) automatically frees resources allocated with `devm_*` functions (e.g., `devm_kzalloc`, `devm_ioremap`) when the driver detaches.
#### C. The Bug (Use-After-Free) The kernel accessed memory at `ffff00000ec28c80`. * **Offset Calculation:** `0xec28c80 - 0xec28c00 = 0x80` bytes? Wait, the report says "located 200 bytes inside". Let's verify: * Buggy address: `...ec28c80` * Object start: `...ec28c00` * Difference: `0x80` (128 decimal). * **Discrepancy Note:** The report states "located 200 bytes inside". This might be due to KASAN shadow memory alignment or a slight offset in how the bug was triggered vs. where the object starts. However, both are within the same 512-byte slab.
### 3. Root Cause Analysis
The most likely scenario is:
> **A driver allocated memory using `devm_*` (managed allocation) during probe/bind, but then accessed that memory after the device was unbound/detached.**
#### Why this happens: 1. During normal operation, a pointer to this object might be stored in a global structure, a workqueue context, or an interrupt handler. 2. When the driver is removed (e.g., `rmmod`, hot-unplug), `device_release_driver` calls `devres_release_all`. 3. This frees all managed resources (`kfree`). 4. **However**, if there is a pending work item, timer, or interrupt handler that still holds a pointer to this freed memory and runs *after* the unbind completes (or concurrently), it will trigger this UAF.
### 4. Common Scenarios Leading to This Bug
| Scenario | Description | |----------|-------------| | **Pending Workqueue** | A `work_struct` was queued before driver removal but not flushed/cancelled properly. It runs after `devm_*` cleanup and accesses freed memory. | | **Interrupt Handler** | An IRQ fires during or after unbind, accessing a data structure that was managed by DevRes. | | **Timer Callback** | A timer callback executes after the driver has been unloaded/freed resources. | | **Race Condition in Probe/Remove** | If `probe` fails partially and then remove is called, but some async task still references allocated memory. |
### 5. How to Fix
#### Step 1: Identify the Buggy Code Path Since the allocation stack trace is truncated (`...`), you need to find where this specific object was originally allocated. Look for `devm_kzalloc`, `devm_kmalloc`, or similar in your driver code near address `ffff00000ec28c00`.
#### Step 2: Ensure Proper Cleanup Ensure that **all** asynchronous tasks are stopped and flushed before the driver releases its managed resources.
##### Example
VulDB is the best source for vulnerability data and more expert information about this specific topic.