Answer in brief
CVE-2026-74540 records a Unknown severity vulnerability in Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp. 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 | >=f1496dee9cbde2a62821f4441dadb0d3360f60c3 <fd4c1e301bdec60a40728ea37de531cbccda501a || >=f1496dee9cbde2a62821f4441dadb0d3360f60c3 <522b730c62c53a1981604fd73524697fd347830d || >=f1496dee9cbde2a62821f4441dadb0d3360f60c3 <58e3c5289ad230a7e24ae4b0c7b43f5ee6e32136 || >=f1496dee9cbde2a62821f4441dadb0d3360f60c3 <09f447accc2570751e7d17f0dc0788b40d3edade || >=f1496dee9cbde2a62821f4441dadb0d3360f60c3 <c4740e7f23ff9a8210198d8b4703259e21b9f69d | fd4c1e301bdec60a40728ea37de531cbccda501a, 522b730c62c53a1981604fd73524697fd347830d, 58e3c5289ad230a7e24ae4b0c7b43f5ee6e32136, 09f447accc2570751e7d17f0dc0788b40d3edade, c4740e7f23ff9a8210198d8b4703259e21b9f69d |
| Linux/Linuxgeneric | 3.14 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-74540 records a Unknown severity vulnerability in Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp. 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 | >=f1496dee9cbde2a62821f4441dadb0d3360f60c3 <fd4c1e301bdec60a40728ea37de531cbccda501a || >=f1496dee9cbde2a62821f4441dadb0d3360f60c3 <522b730c62c53a1981604fd73524697fd347830d || >=f1496dee9cbde2a62821f4441dadb0d3360f60c3 <58e3c5289ad230a7e24ae4b0c7b43f5ee6e32136 || >=f1496dee9cbde2a62821f4441dadb0d3360f60c3 <09f447accc2570751e7d17f0dc0788b40d3edade || >=f1496dee9cbde2a62821f4441dadb0d3360f60c3 <c4740e7f23ff9a8210198d8b4703259e21b9f69d | fd4c1e301bdec60a40728ea37de531cbccda501a, 522b730c62c53a1981604fd73524697fd347830d, 58e3c5289ad230a7e24ae4b0c7b43f5ee6e32136, 09f447accc2570751e7d17f0dc0788b40d3edade, c4740e7f23ff9a8210198d8b4703259e21b9f69d |
| Linux/Linuxgeneric | 3.14 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.
Quoted source text, attributed separately from HOL analysis.