Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix tx ident leak for commands without a response Commit… (CVE-2026-72333)
Severity: mediumType: VulnerabilityCVE-2026-72333
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix tx ident leak for commands without a response Commit 6c3ea155e5ee ("Bluetooth: L2CAP: Fix not tracking outstanding TX ident") changed ident allocation to use an IDA, releasing idents in l2cap_put_ident() when the matching response command is received. But identifiers allocated for commands that have no response defined are never released. In particular L2CAP_LE_CREDITS is sent repeatedly for the lifetime of an LE CoC channel, so a peer streaming data to the host exhausts the 1-255 ident range after 254 credit packets. From then on l2cap_get_ident() fails: kernel: Bluetooth: Unable to allocate ident: -28 and every subsequent L2CAP_LE_CREDITS packet is sent with ident 0, which is invalid (Core Spec, Vol 3, Part A, Section 4: "Signaling identifier 0x00 is an invalid identifier and shall never be used in any command"). Remote stacks that validate the ident drop these commands, never receive new credits, and the channel stalls permanently. With default socket buffers this happens after roughly 0.5 MB of received data (the exact amount depends on the socket receive buffer): < ACL Data TX: Handle 2048 flags 0x00 dlen 12 LE L2CAP: LE Flow Control Credit (0x16) ident 0 len 4 Source CID: 64 Credits: 1 Release the ident immediately after sending L2CAP_LE_CREDITS since no response will ever release it. Use a local variable instead of chan->ident so that an ident that an EXT_FLOWCTL channel may be waiting on (e.g. a pending reconfigure) is not overwritten by a credit packet. Also add the missing L2CAP_LE_CONN_RSP case to l2cap_put_ident() so idents allocated for outgoing L2CAP_LE_CONN_REQ commands are released when the response arrives.
AI Analysis
Technical Summary
The Linux kernel Bluetooth L2CAP subsystem had a flaw where transaction identifiers (idents) allocated for commands without a response, such as L2CAP_LE_CREDITS, were never released. This caused the ident pool (1-255) to be exhausted after about 254 credit packets, resulting in failure to allocate new idents and sending packets with ident 0, which is invalid per Bluetooth Core Specification. Remote peers that enforce ident validation drop these packets, causing the LE CoC channel to stall. The fix involves releasing the ident immediately after sending these commands and adding missing ident release logic for connection response commands.
Potential Impact
Exhaustion of transaction identifiers causes the Bluetooth LE Credit-based Flow Control channel to stall permanently, disrupting data streaming over the channel. This can lead to denial of service for Bluetooth LE connections relying on L2CAP channels, as no new credits are received by the peer and communication halts.
Mitigation Recommendations
A fix is available and has been applied in the Linux kernel to release idents for commands without responses immediately after sending. Users should update to a Linux kernel version that includes this fix. Since this is a kernel vulnerability, patching the kernel is the recommended remediation. Patch status is not explicitly confirmed in the provided data; users should consult the vendor or Linux kernel advisories for the exact fixed versions and update accordingly.
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix tx ident leak for commands without a response Commit… (CVE-2026-72333)
Severity: medium
Type: Vulnerability
CVE: CVE-2026-72333
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix tx ident leak for commands without a response Commit 6c3ea155e5ee ("Bluetooth: L2CAP: Fix not tracking outstanding TX ident") changed ident allocation to use an IDA, releasing idents in l2cap_put_ident() when the matching response command is received. But identifiers allocated for commands that have no response defined are never released. In particular L2CAP_LE_CREDITS is sent repeatedly for the lifetime of an LE CoC channel, so a peer streaming data to the host exhausts the 1-255 ident range after 254 credit packets. From then on l2cap_get_ident() fails: kernel: Bluetooth: Unable to allocate ident: -28 and every subsequent L2CAP_LE_CREDITS packet is sent with ident 0, which is invalid (Core Spec, Vol 3, Part A, Section 4: "Signaling identifier 0x00 is an invalid identifier and shall never be used in any command"). Remote stacks that validate the ident drop these commands, never receive new credits, and the channel stalls permanently. With default socket buffers this happens after roughly 0.5 MB of received data (the exact amount depends on the socket receive buffer): < ACL Data TX: Handle 2048 flags 0x00 dlen 12 LE L2CAP: LE Flow Control Credit (0x16) ident 0 len 4 Source CID: 64 Credits: 1 Release the ident immediately after sending L2CAP_LE_CREDITS since no response will ever release it. Use a local variable instead of chan->ident so that an ident that an EXT_FLOWCTL channel may be waiting on (e.g. a pending reconfigure) is not overwritten by a credit packet. Also add the missing L2CAP_LE_CONN_RSP case to l2cap_put_ident() so idents allocated for outgoing L2CAP_LE_CONN_REQ commands are released when the response arrives.
Technical Summary
The Linux kernel Bluetooth L2CAP subsystem had a flaw where transaction identifiers (idents) allocated for commands without a response, such as L2CAP_LE_CREDITS, were never released. This caused the ident pool (1-255) to be exhausted after about 254 credit packets, resulting in failure to allocate new idents and sending packets with ident 0, which is invalid per Bluetooth Core Specification. Remote peers that enforce ident validation drop these packets, causing the LE CoC channel to stall. The fix involves releasing the ident immediately after sending these commands and adding missing ident release logic for connection response commands.
Potential Impact
Exhaustion of transaction identifiers causes the Bluetooth LE Credit-based Flow Control channel to stall permanently, disrupting data streaming over the channel. This can lead to denial of service for Bluetooth LE connections relying on L2CAP channels, as no new credits are received by the peer and communication halts.
Mitigation Recommendations
A fix is available and has been applied in the Linux kernel to release idents for commands without responses immediately after sending. Users should update to a Linux kernel version that includes this fix. Since this is a kernel vulnerability, patching the kernel is the recommended remediation. Patch status is not explicitly confirmed in the provided data; users should consult the vendor or Linux kernel advisories for the exact fixed versions and update accordingly.
Source: GCVE Database
Published: 08/15/2026
EPSS 0.2%top 90%
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix tx ident leak for commands without a response Commit… (CVE-2026-72333)
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix tx ident leak for commands without a response Commit 6c3ea155e5ee ("Bluetooth: L2CAP: Fix not tracking outstanding TX ident") changed ident allocation to use an IDA, releasing idents in l2cap_put_ident() when the matching response command is received. But identifiers allocated for commands that have no response defined are never released. In particular L2CAP_LE_CREDITS is sent repeatedly for the lifetime of an LE CoC channel, so a peer streaming data to the host exhausts the 1-255 ident range after 254 credit packets. From then on l2cap_get_ident() fails: kernel: Bluetooth: Unable to allocate ident: -28 and every subsequent L2CAP_LE_CREDITS packet is sent with ident 0, which is invalid (Core Spec, Vol 3, Part A, Section 4: "Signaling identifier 0x00 is an invalid identifier and shall never be used in any command"). Remote stacks that validate the ident drop these commands, never receive new credits, and the channel stalls permanently. With default socket buffers this happens after roughly 0.5 MB of received data (the exact amount depends on the socket receive buffer): < ACL Data TX: Handle 2048 flags 0x00 dlen 12 LE L2CAP: LE Flow Control Credit (0x16) ident 0 len 4 Source CID: 64 Credits: 1 Release the ident immediately after sending L2CAP_LE_CREDITS since no response will ever release it. Use a local variable instead of chan->ident so that an ident that an EXT_FLOWCTL channel may be waiting on (e.g. a pending reconfigure) is not overwritten by a credit packet. Also add the missing L2CAP_LE_CONN_RSP case to l2cap_put_ident() so idents allocated for outgoing L2CAP_LE_CONN_REQ commands are released when the response arrives.
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
AILast updated: 08/15/2026, 16:37:17 UTC
Technical Analysis
The Linux kernel Bluetooth L2CAP subsystem had a flaw where transaction identifiers (idents) allocated for commands without a response, such as L2CAP_LE_CREDITS, were never released. This caused the ident pool (1-255) to be exhausted after about 254 credit packets, resulting in failure to allocate new idents and sending packets with ident 0, which is invalid per Bluetooth Core Specification. Remote peers that enforce ident validation drop these packets, causing the LE CoC channel to stall. The fix involves releasing the ident immediately after sending these commands and adding missing ident release logic for connection response commands.
Potential Impact
Exhaustion of transaction identifiers causes the Bluetooth LE Credit-based Flow Control channel to stall permanently, disrupting data streaming over the channel. This can lead to denial of service for Bluetooth LE connections relying on L2CAP channels, as no new credits are received by the peer and communication halts.
Mitigation Recommendations
A fix is available and has been applied in the Linux kernel to release idents for commands without responses immediately after sending. Users should update to a Linux kernel version that includes this fix. Since this is a kernel vulnerability, patching the kernel is the recommended remediation. Patch status is not explicitly confirmed in the provided data; users should consult the vendor or Linux kernel advisories for the exact fixed versions and update accordingly.
Pro Console: star threats, build custom feeds, automate alerts via Slack, email & webhooks.Upgrade to Pro
Technical Details
Gcve Source
db.gcve.eu
Osv Id
GHSA-7qqh-36vf-8r78
Osv Schema Version
1.4.0
Aliases
["CVE-2026-72333"]
Threat ID: 6a808b71bf8831d5394fbd76
Added to database: 08/15/2026, 15:53:21 UTC
Last enriched: 08/15/2026, 16:37:17 UTC
Last updated: 09/30/2026, 03:28:30 UTC
Views: 48
Community Reviews
0 reviews
Crowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Sort by
Loading community insights…
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.