CVE-2024-27398 in Linux
Riassunto
di VulDB • 15/06/2026
Based on the kernel log provided, this is a **KASAN (Kernel Address Sanitizer)** report indicating a **Use-After-Free (UAF)** bug in the Linux Bluetooth SCO (Synchronous Connection-Oriented) socket implementation.
### **Summary of the Bug** - **Type:** Use-After-Free (UAF) - **Component:** Bluetooth SCO Socket (`sco_sock`) - **Trigger:** A socket was freed (via `sco_sock_release` → `kfree`) but then accessed again (likely during socket creation or cleanup in `sco_sock_create` or related paths). - **Memory Region:** A 1024-byte slab object (`kmalloc-1k`) at `ffff88800c388000`. - **Buggy Access:** The access occurred **128 bytes inside** the freed region.
---
### **Detailed Analysis**
#### **1. The "Freed by" Stack Trace** This shows how the memory was freed: ``` [ 95.890755] Freed by task 506:
[ 95.890755] kfree+0xb2/0x240
[ 95.890755] __sk_destruct+0x317/0x410 # Socket destructor
[ 95.890755] sco_sock_release+0x232/0x280 # SCO socket close
[ 95.890755] sock_close+0xb2/0x210
[ 95.890755] __fput+0x37f/0x770
[ 95.890755] task_work_run+0x1ae/0x210
[ 95.890755] get_signal+0xe17/0xf70
[ 95.890755] arch_do_signal_or_restart+0x3f/0x520
[ 95.890755] syscall_exit_to_user_mode+0x55/0x120
[ 95.890755] do_syscall_64+0xd1/0x1b0
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
``` - **Task 506** closed a socket (`sco_sock_release`), which triggered the socket destructor (`__sk_destruct`), which called `kfree` on the `sco_sock` structure.
#### **2. The "Allocated by" Stack Trace (Truncated)** The log shows: ``` [ 95.890755] sco_sock_create+0xad/0x320
[ 95.890755] bt_sock_create+0x145/0x320
[ 95.890755] __sock_create+0x2e1/0x650
[ 95.890755] __sys_socket+0xd0/0x280
[ 95.890755] __x64_sys_socket+0x75/0x80
[ 95.890755] do_syscall_64+0xc4/0x1b0
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
``` - This indicates that the **same memory object** was originally allocated during a `socket()` syscall for a Bluetooth SCO socket (`sco_sock_create`).
#### **3. The Bug** - The memory was **freed** when the socket was closed. - However, it was **accessed again** (the "buggy address" access) **after** it was freed. - The access happened **128 bytes** into the 1024-byte object. This offset likely corresponds to a specific field within the `sco_sock` structure (e.g., a pointer, timer, or list head).
---
### **Root Cause Hypothesis** This is a classic **Use-After-Free** scenario in the Bluetooth SCO subsystem. Possible causes
If you want to get best quality of vulnerability data, you may have to visit VulDB.