Description
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan

For L2CAP sockets without owning sk->sk_socket, reading
l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() ->
l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks,
but access in l2cap_sock_cleanup_listen() has unsafe lockless read.

[Task 1] [Task 2 (hdev->workqueue)]
l2cap_sock_release(parent) l2cap_disconn_cfm
l2cap_sock_cleanup_listen l2cap_conn_del
bt_accept_dequeue l2cap_chan_del
lock_sock(sk) l2cap_sock_teardown_cb
bt_accept_unlink
bt_sk(sk)->parent = NULL
release_sock(sk) ----------------> lock_sock(sk)
parent = /* NULL */
lock_sock(sk) <--------------------- release_sock(sk)
sock_set_flag(sk, SOCK_ZAPPED)
l2cap_sock_close_cb
l2cap_sock_kill(sk)
l2cap_sock_put_chan
chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL
l2cap_chan_hold_unless_zero l2cap_put_chan(chan)
kref_get_unless_zero(&chan->ref)

Task 1 may observe NULL which causes null-ptr-deref.

Fix the race by taking lock_sock() in l2cap_sock_kill() to
synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not
needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL.

Clarify code comments vs. locking.
Published: 2026-09-17
Score: 8 High
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Immediate Patch
AI Analysis

Impact

A race condition in the Linux kernel’s Bluetooth L2CAP implementation allows a concurrent call to l2cap_sock_cleanup_listen() and l2cap_sock_put_chan() to result in an unsafe lockless read of a channel pointer that may be null. This can trigger a null‑pointer dereference in kernel mode, potentially causing a kernel panic and denying service to the system. The weakness is a classic example of improper synchronization that leads to a null pointer dereference.

Affected Systems

The vulnerability affects the Linux kernel’s Bluetooth stack across all versions that include the buggy L2CAP code. No specific kernel release numbers are listed, so any unpatched Linux kernel running the Bluetooth stack is potentially impacted.

Risk and Exploitability

The CVSS score of 8 indicates a high severity. The EPSS score is below 1%, suggesting current exploitation likelihood is low, and the issue is not listed in the CISA KEV catalog. The attack vector is inferred to be remote, via crafted Bluetooth L2CAP traffic that triggers the race, potentially allowing an attacker to force a kernel crash from a Bluetooth connection.

Generated by OpenCVE AI on September 20, 2026 at 04:00 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the latest stable Linux kernel update that includes the L2CAP race condition fix (commit IDs are listed in the provided references).
  • If patching is not immediately possible, disable or restrict the system’s Bluetooth services to prevent L2CAP connections while awaiting the kernel patch.
  • Restrict Bluetooth traffic to trusted devices by configuring a firewall or ACL, or block all L2CAP traffic using kernel parameters until the patch is available.

Generated by OpenCVE AI on September 20, 2026 at 04:00 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Sun, 20 Sep 2026 04:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-410
CWE-476

Fri, 18 Sep 2026 21:30:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 8, 'vector': 'CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking.
Title Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-18T17:52:56.765Z

Reserved: 2026-09-11T19:38:34.786Z

Link: CVE-2026-90091

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:00.563

Modified: 2026-09-18T18:17:41.277

Link: CVE-2026-90091

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-20T04:15:17Z

Weaknesses