CVE Tools

CVE-2026-98290

Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup

No known exploitation. EPSS puts it in the 16th percentile. Fixed versions are out.

Published Updated Sources: CVE.org, NVD

What to do

Find your product and version, then upgrade to the build on the right.

  • LinuxAffected: ≥ b7ce436a5d798bc59e71797952566608a4b4626b, < eb4adaa46e4c9e6efa7be3ce06398f4d7c39b57cUpgrade to: eb4adaa46e4c9e6efa7be3ce06398f4d7c39b57cAffected: ≥ b7ce436a5d798bc59e71797952566608a4b4626b, < 4aafb47301a799d3e01230d6568c4e93524e1523Upgrade to: 4aafb47301a799d3e01230d6568c4e93524e1523Affected: ≥ b7ce436a5d798bc59e71797952566608a4b4626b, < c741977e413f5b49d306700820fb55ccb8269f5aUpgrade to: c741977e413f5b49d306700820fb55ccb8269f5aAffected: ≥ b7ce436a5d798bc59e71797952566608a4b4626b, < c6792c441767256030606eb82dca5d5fc360dd9aUpgrade to: c6792c441767256030606eb82dca5d5fc360dd9a + 3 more branchesStated by: CVE record

Versions as the sources state them. Full version matrix after sign-in

What it is

From the CVE record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup rfcomm_sock_cleanup_listen() closes unaccepted child sockets through rfcomm_sock_close(), which takes the child socket lock before rfcomm_dlc_close() acquires rfcomm_mutex. The RFCOMM worker takes these locks in reverse order while handling connections and DLC state changes, so lockdep reports a possible deadlock. Close dequeued children without taking their socket lock. The accept queue owns a reference to each child, and bt_accept_dequeue() locks the child while unlinking it and clearing its parent pointer. Dropping the child lock makes it important to prevent a concurrent rfcomm_connect_ind() from enqueueing a new child after cleanup observes an empty queue. Set a listening socket to BT_CLOSED while its lock is still held, before dropping the lock and draining the queue. The state check in rfcomm_connect_ind() then rejects new children once cleanup starts.

In plain language

No plain-language summary for this CVE yet.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS16th
CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.3% chance of exploitation activity in the next 30 days, which ranks it in the 16th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

3 events over 1 day, from the signal feeds we watch.

  1. Record updated
  2. Publishedrecord updated

Affected products

Technical detail

CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Scored 7.5 by NVD.

How it is reached

  • Attack Vector AdjacentRequires access to the local network (e.g. same Wi-Fi, Bluetooth)
  • Attack Complexity HighRequires specific conditions like a race condition or non-default configuration
  • Privileges Required NoneNo authentication required — anyone can exploit this
  • User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

  • Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

  • Confidentiality HighTotal information disclosure — all data in the component is compromised
  • Integrity HighTotal loss of integrity — attacker can modify any data in the component
  • Availability HighTotal denial of service — the component is completely unavailable

Sources

Watch the software you run.

My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.

We'll flag the next CVE, public exploit or patch for Linux, not every advisory.