Skip to main content
VulnerabilityPublished Updated

CVE-2026-53256: Linux kernel · Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 8.0 High · fixed in f5ec76bdbeb80f75ad0be204371afffee0f8fac8 : patch Linux kernel soon.

Data as of 26 Oct 2026, 17:30 UTC

CVSS 3.1 base score
8.0High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.2% chance of exploitation in 30 days – higher than 18% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in f5ec76bdbeb80f75ad0be204371afffee0f8fac8, de31973ef00e5aa55496f84cf6a44bb157a34e02, b0e33e409715c617e2a20f46f99aa5403a14dfda +5
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 25 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < f5ec76bdbeb80f75ad0be204371afffee0f8fac8
Fixed in
  • f5ec76bdbeb80f75ad0be204371afffee0f8fac8
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < de31973ef00e5aa55496f84cf6a44bb157a34e02
Fixed in
  • de31973ef00e5aa55496f84cf6a44bb157a34e02
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < b0e33e409715c617e2a20f46f99aa5403a14dfda
Fixed in
  • b0e33e409715c617e2a20f46f99aa5403a14dfda
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < a07d741c077d4e34b16458241a94d29039386553
Fixed in
  • a07d741c077d4e34b16458241a94d29039386553
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 8802413ce63175fb522a2bd609fb043a3550c720
Fixed in
  • 8802413ce63175fb522a2bd609fb043a3550c720
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 43c441edacf953b39517a44f5e5e10a93618b226
Fixed in
  • 43c441edacf953b39517a44f5e5e10a93618b226

Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().

References

Community reviews

Loading reviews…