CVE-2026-98246 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: Serialize local codec list cleanup
hci_dev_close_sync() clears hdev->local_codecs after releasing hdev->lock. Codec list additions and both traversals in sco_sock_getsockopt() use that lock, but the close path does not. A close and BT_CODEC query can therefore interleave as follows:
hci_dev_close_sync() sco_sock_getsockopt() hci_dev_lock() fetch codec entry hci_codec_list_clear() kfree(entry) read entry->id
The reader then accesses an entry which the close path has freed. KASAN
BUG: KASAN: slab-use-after-free in sco_sock_getsockopt+0xfa0/0xfe0 Read of size 1 at addr ffff8881001c3450 Call Trace: sco_sock_getsockopt+0xfa0/0xfe0 do_sock_getsockopt+0x537/0x7b0 __sys_getsockopt+0xf2/0x170 Allocated by task 92: hci_codec_list_add.isra.0+0x2c/0x440 hci_read_codec_capabilities+0x224/0x590 hci_read_supported_codecs+0x2c2/0x640 Freed by task 92: kfree+0x131/0x3c0 hci_codec_list_clear+0xd8/0x160 hci_dev_close_sync+0x92a/0xfa0
Take hdev->lock around the clear operation at its existing point in the close path. This makes the clear wait for active readers and prevents a new traversal until the list is empty without changing teardown ordering.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel Bluetooth subsystem contains a concurrency vulnerability within the HCI synchronization layer, specifically involving the management of local codec lists during device closure operations. The core issue stems from an improper locking strategy in the hci_dev_close_sync function, which clears the hdev->local_codecs list after releasing the hdev lock. This sequencing error creates a race condition because other subsystem components, such as sco_sock_getsockopt, rely on that same lock to safely traverse or modify the codec list. When the close path releases the lock before clearing the data structures, it allows concurrent access paths to proceed without synchronization guarantees, leading to potential memory corruption and system instability.
The technical flaw manifests when a Bluetooth device is being closed while another process simultaneously queries for codec capabilities via socket options. The hci_dev_close_sync function proceeds to free individual codec entries using kfree after unlocking the mutex. However, because sco_sock_getsockopt acquires the lock only during its traversal phase, it may begin reading an entry that has already been freed by the close path if the timing aligns unfavorably. This results in a use-after-free condition where the reader accesses memory that is no longer validly allocated to the process or kernel context. The vulnerability allows for arbitrary read operations on previously released slab objects, which can lead to information disclosure of sensitive kernel data structures or potentially trigger crashes depending on how the freed memory is subsequently reused by other allocations.
From a security classification perspective, this defect aligns with CWE-416, Use After Free, as it involves accessing memory after it has been returned to the system for reuse without ensuring that no active references remain. In terms of adversarial tactics, this vulnerability could be leveraged within ATT&CK technique T1059, Command and Scripting Interpreter, if an attacker can trigger the race condition through local socket operations to execute arbitrary code or escalate privileges by corrupting kernel memory structures. The impact extends beyond simple denial of service; successful exploitation could allow a local user with access to Bluetooth sockets to read sensitive kernel memory contents, potentially revealing cryptographic keys or other confidential information stored in adjacent allocations that overwrite the freed codec entries.
The operational impact includes system instability and potential privilege escalation for unprivileged users who can interact with Bluetooth interfaces. The KASAN trace confirms that reads occur at invalid addresses after allocation release, indicating a high severity risk to kernel integrity. Mitigation requires immediate patching of the Linux kernel to correct the locking scope in hci_dev_close_sync. The fix involves taking the hdev lock around the clear operation rather than releasing it beforehand. This ensures that any active readers holding or attempting to acquire the lock will block until the list is safely cleared, preventing interleaved execution between traversal and deallocation. System administrators should apply kernel updates promptly and restrict Bluetooth socket access where possible to reduce the attack surface for local exploitation attempts.