{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.170-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.85-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.19.12-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: SCO: fix race conditions in sco_sock_connect()  sco_sock_connect() checks sk_state and sk_type without holding the socket lock. Two concurrent connect() syscalls on the same socket can both pass the check and enter sco_connect(), leading to use-after-free.  The buggy scenario involves three participants and was confirmed with additional logging instrumentation:    Thread A (connect):    HCI disconnect:      Thread B (connect):    sco_sock_connect(sk)                        sco_sock_connect(sk)   sk_state==BT_OPEN                           sk_state==BT_OPEN   (pass, no lock)                             (pass, no lock)   sco_connect(sk):                            sco_connect(sk):     hci_dev_lock                                hci_dev_lock     hci_connect_sco                               \u003c- blocked       -\u003e hcon1     sco_conn_add-\u003econn1     lock_sock(sk)     sco_chan_add:       conn1-\u003esk = sk       sk-\u003econn = conn1     sk_state=BT_CONNECT     release_sock     hci_dev_unlock                            hci_dev_lock                            sco_conn_del:                              lock_sock(sk)                              sco_chan_del:                                sk-\u003econn=NULL                                conn1-\u003esk=NULL                                sk_state=                                  BT_CLOSED                                SOCK_ZAPPED                              release_sock                            hci_dev_unlock                                                   (unblocked)                                                   hci_connect_sco                                                     -\u003e hcon2                                                   sco_conn_add                                                     -\u003e conn2                                                   lock_sock(sk)                                                   sco_chan_add:                                                     sk-\u003econn=conn2                                                   sk_state=                                                     BT_CONNECT                                                   // zombie sk!                                                   release_sock                                                   hci_dev_unlock  Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to BT_CONNECT. Subsequent cleanup triggers double sock_put() and use-after-free. Meanwhile conn1 is leaked as it was orphaned when sco_conn_del() cleared the association.  Fix this by: - Moving lock_sock() before the sk_state/sk_type checks in   sco_sock_connect() to serialize concurrent connect attempts - Fixing the sk_type != SOCK_SEQPACKET check to actually   return the error instead of just assigning it - Adding a state re-check in sco_connect() after lock_sock()   to catch state changes during the window between the locks - Adding sco_pi(sk)-\u003econn check in sco_chan_add() to prevent   double-attach of a socket to multiple connections - Adding hci_conn_drop() on sco_chan_add failure to prevent   HCI connection leaks",
  "id": "DEBIAN-CVE-2026-43023",
  "modified": "2026-09-14T16:47:39.919788889Z",
  "published": "2026-05-01T15:16:46.610Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-43023"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-43023"
  ]
}