CVE-2026-43023

What it actually does

This is a local Linux kernel race condition in the Bluetooth SCO socket connect path. Two concurrent connect() calls against the same SCO socket can pass state and type checks before the socket is locked, allowing the socket to be attached to multiple SCO/HCI connection objects across an asynchronous disconnect. That can revive a closed/zapped socket, leak a connection object, and later trigger double reference release and use-after-free in kernel memory. With local code execution and access to Bluetooth socket functionality, successful exploitation could cause kernel memory corruption, denial of service, and potentially local privilege escalation with kernel-level code execution.

Why it matters to the business

An attacker who already has a local foothold on a Linux system may be able to crash the host or potentially gain full control of it by exploiting Bluetooth kernel code. The risk is most relevant on workstations, laptops, mobile/embedded Linux devices, kiosks, IoT systems, and servers where Bluetooth support is enabled or Bluetooth kernel modules are available. The issue is not known to be exploited in the wild, is not in CISA KEV, has very low EPSS, and has no reported mature public exploit, so it is generally a patch-management priority rather than an emergency internet-facing incident; however, kernel privilege-escalation bugs should still be remediated promptly on multi-user or exposed endpoint fleets.

How an attack unfolds

An attacker first obtains the ability to run local unprivileged code on a vulnerable Linux system and confirms that Bluetooth SCO sockets are available. The attacker creates a SCO Bluetooth socket and orchestrates two concurrent connect() operations on the same socket while also relying on, or inducing, an HCI disconnect timing window. Because the vulnerable code checks socket state and type before taking the socket lock, both connect paths can proceed as if the socket is valid and open. One path attaches the socket to a SCO connection, while a disconnect path clears the association and marks the socket closed/zapped. The second connect path can then attach a new connection to the same socket and move it back into a connecting state. Subsequent cleanup can release the same socket reference twice and access freed kernel memory. Depending on kernel configuration, heap layout, timing reliability, and exploit sophistication, this may produce a kernel crash or be shaped into privilege escalation.

How to fix it

Upgrade to a Linux kernel build that includes the upstream Bluetooth SCO locking and state-validation fixes for this issue. Because no exact fixed package versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution or vendor, and verify that the vendor advisory explicitly references this vulnerability or the Bluetooth SCO sco_sock_connect() race fix. Prioritize systems with Bluetooth enabled, shared user access, untrusted local workloads, or endpoint exposure. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, blocking or unloading Bluetooth-related kernel modules where operationally safe, restricting local shell/code execution, and hardening endpoint controls that prevent untrusted users from running arbitrary binaries. Potential mitigations include disabling the Bluetooth service, disabling Bluetooth hardware in firmware/BIOS where feasible, preventing autoloading of Bluetooth modules, or applying kernel module blacklist policies for unused Bluetooth components; validate these mitigations carefully because module names and dependencies vary by distribution and device role.

How to confirm the fix worked

Confirm the running kernel is updated to a vendor-fixed build, not merely that a package is installed on disk. Check the active kernel version after reboot with uname -a or equivalent fleet inventory tooling, and compare it with the vendor security advisory for the distribution. Confirm that Bluetooth exposure is reduced where mitigation is used by checking service state, loaded modules, and availability of Bluetooth sockets. On test systems, validate that the host is running the patched kernel containing the sco_sock_connect() locking/state re-check changes. For mitigated systems, verify Bluetooth is disabled or unavailable after reboot and cannot be re-enabled by unprivileged users. Review kernel logs for absence of recurring Bluetooth SCO crashes, kernel oops, KASAN reports, use-after-free reports, or warnings involving sco_sock_connect(), sco_connect(), sco_chan_add(), or sco_conn_del().

Typical attack path

1. Gain local code execution on a Linux system, such as through a user account, compromised application, or malicious local program.
2. Determine that Bluetooth support and SCO socket functionality are enabled and reachable.
3. Create a Bluetooth SCO socket and prepare concurrent execution contexts such as threads or processes sharing the same socket.
4. Issue overlapping connect() calls on the same socket while triggering or racing an HCI disconnect path.
5. Exploit the missing socket-lock serialization so both connect paths pass stale state checks.
6. Cause the socket to be detached, marked closed/zapped, and then incorrectly reattached to a new SCO connection.
7. Trigger cleanup paths that produce double sock_put(), use-after-free, or related kernel memory corruption.
8. Use the resulting condition to crash the kernel or, if exploitation is reliable enough, attempt local privilege escalation.

How to detect it

This vulnerability is difficult to detect conclusively after the fact because successful exploitation may leave only kernel crash or memory-corruption artifacts rather than a unique network indicator. Review kernel logs, system journal, crash dumps, pstore/ramoops data, and EDR process telemetry for local processes interacting with Bluetooth sockets immediately before a kernel oops, panic, KASAN report, or unexpected reboot. Useful log sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, kernel crash dump facilities such as kdump/vmcore, pstore, auditd syscall telemetry where configured, and endpoint telemetry showing local process execution. Look for repeated or unusual SCO/Bluetooth socket activity, kernel reports mentioning sco_sock_connect(), sco_connect(), sco_chan_add(), sco_chan_del(), sco_conn_del(), double sock_put(), use-after-free, refcount corruption, or general protection faults in Bluetooth kernel paths. Investigate any crash where the stack trace includes net/bluetooth/sco.c or HCI/SCO connection cleanup functions, especially if preceded by an untrusted local process running from temporary directories or a user-writable location. Absence of these artifacts does not prove non-exploitation, because exploitation attempts may only cause transient instability or may not be logged before a panic.

• sco_sock_connect
• sco_connect
• sco_chan_add
• sco_chan_del
• sco_conn_del
• net/bluetooth/sco.c
• Bluetooth: SCO
• use-after-free
• double sock_put
• BUG: KASAN
• KASAN: use-after-free
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• BUG: unable to handle kernel
• SOCK_ZAPPED
• BT_CLOSED
• BT_CONNECT

What your security team should do

• Inventory Linux systems with Bluetooth hardware, Bluetooth services enabled, or Bluetooth kernel modules loaded, and prioritize those assets for remediation.
• Patch affected Linux kernels using vendor-provided fixed packages and reboot systems to ensure the fixed kernel is active.
• Prioritize laptops, workstations, kiosks, embedded Linux devices, and multi-user systems where local privilege escalation would materially increase risk.
• Where Bluetooth is unnecessary, disable Bluetooth services and prevent Bluetooth kernel modules from loading as a defense-in-depth mitigation.
• Monitor kernel logs and EDR telemetry for Bluetooth SCO-related kernel crashes, KASAN use-after-free reports, and suspicious local programs repeatedly creating Bluetooth sockets.
• Treat exploitation signs as potential local privilege-escalation activity: isolate the host, preserve volatile evidence, collect kernel logs, and investigate the local user/process responsible.
• Because this issue is not currently KEV-listed, has very low EPSS, and has no known mature exploit, align remediation with normal kernel patch cycles unless Bluetooth-enabled shared systems or high-risk endpoints are present.