Linux KernelOperating system · Linux
CVE-2026-53358
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceA lock inversion vulnerability exists in the Linux kernel's Bluetooth L2CAP implementation where l2cap_chan_close() acquires conn->lock while cleanup_listen() already holds sk_lock, violating the established lock ordering and risking deadlock. The fix schedules l2cap_chan_timeout with zero delay to close channels asynchronously, allowing the timeout handler to acquire locks in the correct order.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data
Linux KernelOperating system
>= 3.4, < 5.10.259>= 5.11, < 5.15.210>= 5.16, < 6.1.176>= 6.2, < 6.6.143>= 6.7, < 6.12.93>= 6.13, < 6.18.35>= 6.19, < 7.0.12= 7.1CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Adjacent
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Confirm Bluetooth L2CAP is in useCheck if Bluetooth is enabled and L2CAP channels are active. Run 'hciconfig -a' to list Bluetooth adapters, and 'cat /proc/bluetooth/l2cap' or check 'btmon' logs for L2CAP connection activity.Affected if The system actively uses Bluetooth L2CAP connections (e.g., audio streaming via A2DP, HID, or other L2CAP-based profiles).
-
Check kernel versionRun 'uname -r' to get the running kernel version. Compare against any kernel updates that include the L2CAP fix. Since no specific version is provided, treat versions without the fix as potentially affected.Affected if The kernel version predates the security fix for this lock-ordering bug.
-
Verify L2CAP kernel module statusRun 'lsmod | grep bluetooth' and 'lsmod | grep l2cap' to check if the Bluetooth and L2CAP modules are loaded. Also check 'cat /sys/module/bluetooth/parameters/l2cap' if available.Affected if The L2CAP module is loaded and the kernel lacks the fix.
-
Inspect cleanup_listen function for the fix patternIf kernel source is accessible, locate the cleanup_listen function in net/bluetooth/l2cap_core.c. Search for 'l2cap_chan_timeout' being scheduled with a delay (often delay=0 or similar). The vulnerable code directly calls l2cap_chan_close() while holding sk_lock; the fixed code schedules this asynchronously.Affected if The function directly calls l2cap_chan_close() without scheduling via l2cap_chan_timeout, indicating the vulnerability is present.
-
Check for deadlocks or lock inversion warningsReview kernel logs ('dmesg' or 'journalctl -k') for any 'INFO: trying to register non-recursive lock' or 'possible deadlock' messages related to Bluetooth, l2cap, or sk_lock. Also check 'lockdep' warnings in dmesg.Affected if Lock inversion warnings involving l2cap_chan_close, sk_lock, or conn->lock appear in kernel logs.
The system is affected if it runs a Linux kernel without the L2CAP fix, has Bluetooth L2CAP enabled and actively in use, and exhibits lock inversion behavior in the kernel logs.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
From vendor data5.10.2595.15.2106.1.176
Apply the kernel patch or update to a Linux kernel version containing the fix. For production systems, this typically involves scheduling a maintenance window to apply the vendor-supplied kernel update.
Fix this in Linux Kernel
Scoped from the published advisory
- Consultation3.0 h
- Implementation6.0 h
- Testing4.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,224.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-53358 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-53358 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data