---
id: CVE-2026-90092
title: |-
  In the Linux kernel, the following vulnerability has been resolved:

  Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN

  New sk should not be added to parent socket accept queue after last
  l2cap_sock_cleanup_listen() has run in l…
summary: |-
  In the Linux kernel, the following vulnerability has been resolved:

  Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN

  New sk should not be added to parent socket accept queue after last
  l2cap_sock_cleanup_listen() has run in l…
severity: high
cvss: 8
cvssVector: 'CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 0c17c8832562b2aac288e89cefd0f46074f54bcb <
    bf61a65c6093970e3b50031c4b79ebf3bd411eba
  - >-
    Linux >= 5105f3e6b2df619c635b5f6a49fac131a36c7952 <
    491e4c60017969b053888029998d2a61f298986a
  - >-
    Linux >= c88c185ae0a1067823661b220aeea613df2c127b <
    2a3a27aaf19bf069720e024ce6fde54e6bf80df9
  - >-
    Linux >= 1810e42ff6716f320c7269d5850eca48b07b7427 <
    87276dc15b559d32757a43b4415c8445fbae06c4
  - >-
    Linux >= 2ff1a41a912de8517b4482e946dd951b7d80edbf <
    c47339e169bf4a0a4cfabb91351471f67744c2bc
  - >-
    Linux >= 2ff1a41a912de8517b4482e946dd951b7d80edbf <
    d4bfa78fd67929b62b02013c107973e0c5b7aa9a
  - Linux 1b1c0da227bf63479bac9982fc8d12df9aaea0fb
  - Linux 85426e97dc72f2088ba6d27e74cd58c3fbd43e31
  - Linux a2dcf1a61d056aef15b63c6eae9441344d624389
  - Linux >= 6.1.175 < 6.1.188
  - Linux >= 6.6.140 < 6.6.157
  - Linux >= 6.12.88 < 6.12.110
  - Linux >= 6.18.30 < 6.18.52
  - Linux >= 5.10.258 < 5.11
  - Linux >= 5.15.209 < 5.16
  - Linux >= 7.0.7 < 7.1
  - Linux 7.1
published: '2026-09-17'
updated: '2026-09-18'
sourceUpdated: '2026-09-18T18:17:41.517'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-90092'
references:
  - url: 'https://git.kernel.org/stable/c/2a3a27aaf19bf069720e024ce6fde54e6bf80df9'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/491e4c60017969b053888029998d2a61f298986a'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/87276dc15b559d32757a43b4415c8445fbae06c4'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/bf61a65c6093970e3b50031c4b79ebf3bd411eba'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/c47339e169bf4a0a4cfabb91351471f67744c2bc'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/d4bfa78fd67929b62b02013c107973e0c5b7aa9a'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
epss: 0.00415
epssPercentile: 0.33049
ingestedAt: '2026-09-17T16:21:47.892Z'
---

## Overview

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

Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN

New sk should not be added to parent socket accept queue after last
l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and
state set to BT_CLOSED, as that can result to UAF on dereferencing the
dangling parent reference.

l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown,
due to chan->state accessed without consistent locking:

  [Task 1]                           [Task 2]
  l2cap_sock_release(parent)         l2cap_connect
    l2cap_sock_shutdown                pchan = l2cap_global_chan_by_psm
      l2cap_chan_lock(pchan)
      l2cap_chan_close
        l2cap_sock_teardown_cb
          pchan->state = BT_CLOSED
      l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan)
                                       l2cap_new_connection
                                         l2cap_sock_new_connection_cb
      l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan)
      l2cap_sock_kill(parent)          /* bt_sk(sk)->parent dangling */

Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in
l2cap_sock_new_connection_cb().  Add lock_sock() around sk_state writes
where missing, to avoid data races.

Although the data races on pchan->state should be fixed too, this
defensive sk_state check probably makes sense in any case.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.