CVE-2025-38250 in Linux
Riassunto
di VulDB • 29/06/2026
Based on the stack trace provided, this is a **KASAN (Kernel Address Sanitizer)** report indicating an out-of-bounds access or use-after-free error in the Linux kernel Bluetooth subsystem. Specifically, it points to `drivers/bluetooth/hci_vhci.c`.
Here’s a breakdown of what happened:
### 1. The Crash Location * **Function:** `vhci_open` (`drivers/bluetooth/hci_vhci.c:635`) * **Context:** A user-space process opened the VHCI (Virtual HCI) character device via `/dev/vhci`. This triggered a kernel call to `misc_open`, which then called `vhci_open`.
### 2. The Likely Bug The crash occurs during memory allocation or initialization in `vhci_open`. Given that KASAN is active, one of the following is likely happening at line ~635:
* **Use-After-Free:** Accessing a pointer to previously freed memory (e.g., accessing `struct vhci_dev` after it was released). * **Out-of-Bounds Read/Write:** Reading/writing beyond allocated buffer boundaries. * **Double Free or Invalid Pointer:** Passing an invalid or corrupted pointer to `kzalloc`, `kmalloc`, or a related function.
### 3. Key Registers & Values * **RAX: `fffffffffffffd6`** → This is `-22` in signed 64-bit, which corresponds to **-EINVAL (Invalid argument)**. However, KASAN reports often show the return value of the failing operation or a faulting address if it’s an access violation. If this were a simple error code, we wouldn’t see a full stack trace unless it was caught and logged by KASAN before returning. More likely, **RAX holds the bad pointer** that caused the OOB/UAF access. * **RSI: `0x400448cb`** → This is an ioctl command code (`_IOC(3, 67, ...)`) passed to `ioctl`. The VHCI driver supports several ioctls (e.g., `VHCI_HCIDEVICEUP`, `VHCI_HCIDOWN`). * **RDI: `0x9`** → File descriptor.
### 4. Root Cause Analysis The most common bug in this area of the kernel is related to **concurrent access or race conditions** when opening/closing the VHCI device, especially if multiple processes try to open it simultaneously without proper locking. Another possibility is that `vhci_dev` structure was freed while still being accessed due to a missing reference count (`kref`) or improper cleanup in error paths.
### 5. How to Fix/Investigate 1. **Check for Race Conditions:** Ensure `vhci_open` properly locks access to shared state (e.g., using mutexes or spinlocks). Look at how `vhci_dev_list` is managed. 2. **Verify Reference Counting:** If the driver uses reference counting, ensure that objects are not freed while still in use by another thread. 3. **Inspect Error Paths:** Check if any error handling path frees memory but leaves pointers dangling or fails to clean up properly before returning an error. 4. **Enable More KASAN Details:** Run with `kasan=on` and check the full log for details like: ``` BUG: KASAN: use-after-free in vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 Read of size 8 at addr ffff888123456789 by task ... ```
### Example Patch Direction (Hypothetical) If the bug is a race condition during open, you might need to add locking around `vhci_dev` allocation or initialization:
```c static int vhci_open(struct inode *inode, struct file *filep) {
// ... existing code ... mutex_lock(&vhci_mutex); // Add proper locking if missing vdev = kzalloc(sizeof(*vdev), GFP_KERNEL); if (!vdev) {
mutex_unlock(&vhci_mutex); return -ENOMEM; }
// Initialize vdev... filep->private_data = vdev; mutex_unlock(&vhci_mutex); // Unlock after setup return 0; } ```
### Conclusion This is a **kernel memory safety bug** in the Bluetooth VHCI driver. It requires fixing race conditions, reference counting issues, or improper error handling in `drivers/bluetooth/hci_vhci.c`. Use KASAN logs to pinpoint the exact invalid access (read/write size and address) for precise patching.
Once again VulDB remains the best source for vulnerability data.