Answer in brief
CVE-2026-31499 records a Unknown severity vulnerability in Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=f87271d21dd4ee83857ca11b94e7b4952749bbae <f7f35a4f7fd574f5889bb2e4b397e14cbb83f6da || >=ab4eedb790cae44313759b50fe47da285e2519d5 <3f26ecbd9cde621dd94be7ef252c7210b965a5c7 || >=ab4eedb790cae44313759b50fe47da285e2519d5 <d008460de352e534f6721de829b093368564ec66 || >=ab4eedb790cae44313759b50fe47da285e2519d5 <00fdebbbc557a2fc21321ff2eaa22fd70c078608 || efc30877bd4bc85fefe98d80af60fafc86e5775e || 18ab6b6078fa8191ca30a3065d57bf35d5635761 || >=6.12.20 <6.12.88 || >=6.6.84 <6.7 || >=6.13.8 <6.14 | f7f35a4f7fd574f5889bb2e4b397e14cbb83f6da, 3f26ecbd9cde621dd94be7ef252c7210b965a5c7, d008460de352e534f6721de829b093368564ec66, 00fdebbbc557a2fc21321ff2eaa22fd70c078608, 6.12.88, 6.7, 6.14 |
| Linux/Linuxgeneric | 6.14 | Not reported |
Published upstream
Apr 22, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Nov 5, 2026
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del() l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer and id_addr_timer while holding conn->lock. However, the work functions l2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2cap_conn_del() takes the lock. Move the work cancellations before acquiring conn->lock and use disable_delayed_work_sync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hci_conn_del().
Quoted source text, attributed separately from HOL analysis.