CVE-2026-63945
High · 7.8CVSS
7.8
EPSS
0.1%
Published
Jul 19, 2026
CISA due date
—
Cloudanix analysis
A flaw in Linux Bluetooth handling could let someone with local access crash a device or possibly take full control of it if the system is not updated.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
This is a race condition in the Linux kernel Bluetooth ISO socket handling code. During ISO socket close, the kernel clears a delayed timeout work item before holding the socket lock, while another path can concurrently delete the ISO connection and set the socket connection pointer to NULL. Because the connection pointer is read without synchronization, the kernel can dereference a NULL pointer or operate on freed memory. The practical outcomes are kernel crash, denial of service, and potentially local privilege escalation if the use-after-free condition can be shaped into controlled memory corruption.
Why it matters to the business
Systems with vulnerable Linux kernels and Bluetooth ISO functionality exposed may be susceptible to local attacks that can crash the host or potentially allow an authenticated local user to gain elevated privileges. The risk is most relevant for laptops, desktops, mobile/embedded Linux devices, and servers with Bluetooth enabled or accessible. Although there is no known exploitation or CISA KEV listing at this time and EPSS is low, kernel privilege-escalation flaws should still be prioritized because successful exploitation can undermine the entire host.
How an attack unfolds
An attacker must already have local code execution or a local account on a vulnerable Linux system. They interact with the Bluetooth ISO socket interface and repeatedly create, close, and tear down ISO socket connections in a way that races iso_sock_close() against connection deletion. If the timing lands correctly, iso_sock_clear_timer() observes a non-NULL connection pointer, but another thread clears or frees that connection before the delayed work cancellation uses it. The most direct result is a kernel NULL pointer dereference or use-after-free crash. With additional heap grooming and exploit development, the use-after-free path may be usable to corrupt kernel memory and execute code with kernel privileges.
How to fix it
Apply vendor-provided Linux kernel updates that include the Bluetooth ISO locking fix. The fix serializes iso_sock_clear_timer() with the socket lock by moving the timer cleanup inside the lock_sock()/release_sock() critical section. No exact fixed package versions were provided in the input, so remediation should follow the relevant Linux distribution, appliance, or kernel vendor advisory for this CVE. Where immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, preventing untrusted local users from accessing Bluetooth functionality, restricting local shell access, and using standard kernel hardening controls such as lockdown mode, module restrictions, and mandatory access controls.
How to confirm the fix worked
Confirm the running kernel version includes the vendor backport or upstream fix for the Bluetooth ISO socket locking issue. Validate using distribution package metadata, kernel changelogs, or vendor advisories rather than relying only on upstream version numbers, because many distributions backport security fixes. Check whether Bluetooth is enabled and whether the bluetooth, btusb, or related modules are loaded. After patching, reboot into the fixed kernel and verify with uname and package manager queries that the active kernel is the updated one. For mitigation validation, confirm Bluetooth is disabled or blocked where not needed and that untrusted users cannot load Bluetooth modules or access relevant local interfaces.
Typical attack path
- Obtain local code execution or access to a low-privileged local account on a vulnerable Linux host.
- Confirm Bluetooth support is present and that the kernel exposes Bluetooth ISO socket functionality.
- Create and manipulate Bluetooth ISO sockets while concurrently closing sockets and forcing connection teardown.
- Trigger the race between ISO socket timer cleanup and ISO connection deletion.
- Cause a kernel NULL pointer dereference or use-after-free condition.
- Use the condition to crash the system, or, with a more advanced exploit, attempt kernel memory corruption for privilege escalation.
How to detect it
Review kernel logs, crash dumps, system journal entries, and endpoint telemetry for signs of Bluetooth ISO socket crashes or memory-safety faults. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, kdump/vmcore artifacts, ABRT/apport crash reports, KASAN/KMSAN reports, and EDR process telemetry for local programs repeatedly creating Bluetooth sockets. Look for kernel oops or panic events referencing ISO Bluetooth functions, delayed work cancellation, NULL pointer dereferences, general protection faults, or use-after-free findings. Because exploitation is local and may only leave a crash artifact, absence of network indicators does not rule out exploitation. If a crash occurred, preserve the vmcore and correlate the timestamp with local user sessions, newly executed binaries, suspicious compiler/interpreter activity, and repeated Bluetooth subsystem access.
- iso_sock_clear_timer
- iso_sock_close
- iso_conn_del
- iso_chan_del
- Bluetooth: ISO
- bt_iso
- NULL pointer dereference
- BUG: kernel NULL pointer dereference
- KASAN: use-after-free
- general protection fault
- cancel_delayed_work
- kernel panic
- Oops:
- /var/crash
- /var/lib/systemd/coredump
- /proc/vmcore
- bluetooth
- btusb
What your security team should do
- Prioritize patching vulnerable Linux kernels on endpoints and embedded systems with Bluetooth enabled or physically accessible users.
- Reboot systems after kernel updates and verify the fixed kernel is actually running, not merely installed.
- Disable Bluetooth on systems where it is not operationally required, especially shared workstations, kiosks, appliances, and servers.
- Monitor for kernel crashes, oops reports, KASAN use-after-free findings, or repeated Bluetooth ISO socket activity preceding host instability.
- Restrict local interactive access and untrusted code execution on systems that cannot be patched promptly.
- Track vendor advisories for exact fixed kernel package versions and deploy distribution-specific updates as they become available.
The record
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock iso_sock_close() calls iso_sock_clear_timer() before acquiring lock_sock(sk). iso_sock_clear_timer() reads iso_pi(sk)->conn twice without the socket lock held: if (!iso_pi(sk)->conn) return; cancel_delayed_work(&iso_pi(sk)->conn->timeout_work); Concurrently, iso_conn_del() executes under lock_sock(sk) and calls iso_chan_del(), which sets iso_pi(sk)->conn to NULL and may result in the final reference to the connection being dropped: CPU0 CPU1 ---- ---- iso_sock_clear_timer() if (conn != NULL) ... lock_sock(sk) iso_chan_del() iso_pi(sk)->conn = NULL cancel_delayed_work(conn) /* NULL deref or UAF */ iso_pi(sk)->conn is not stable across the unlock window, causing a NULL pointer dereference or use-after-free. Serialize iso_sock_clear_timer() with the socket lock by moving it inside lock_sock()/release_sock(), matching the pattern used in iso_conn_del() and all other call sites.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|