UBUNTU-CVE-2026-72333: Medium severity ubuntu/linux-hwe-edge vulnerability
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 l2capputident() when the matching response command is received. But identifiers allocated for commands that have no response defined are never released. In particular L2CAPLECREDITS 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 l2capgetident() fails: kernel: Bluetooth: Unable to allocate ident: -28 and every subsequent L2CAPLECREDITS 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 L2CAPLECREDITS since no response will ever release it. Use a local variable instead of chan->ident so that an ident that an EXTFLOWCTL channel may be waiting on (e.g. a pending reconfigure) is not overwritten by a credit packet. Also add the missing L2CAPLECONNRSP case to l2capputident() so idents allocated for outgoing L2CAPLECONNREQ commands are released when the response arrives.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-nvidia-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1024.25~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-nvidia-bosto a version that resolves this vulnerability.Fixed in 7.0.0-2022.23 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Compensating control
Add the L2CAP_LE_CONN_RSP case to l2cap_put_ident() so identifiers allocated for outgoing L2CAP_LE_CONN_REQ commands are released when the response arrives.
- Compensating control
Release the identifier immediately after sending L2CAP_LE_CREDITS, because no response will release it.
- Compensating control
Use a local variable instead of chan->ident when sending a credit packet so an identifier that an EXT_FLOWCTL channel is waiting on, such as for a pending reconfigure, is not overwritten.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using an affected Ubuntu Linux kernel and accepting Bluetooth LE Credit-Based Connection-Oriented Channel (LE CoC) traffic are exposed. The issue is triggered by a connected peer streaming data to the host over an LE CoC channel.
Does exploitation require authentication or user interaction?
No. The supplied vector indicates adjacent Bluetooth-network access with low attack complexity, no privileges, and no user interaction required.
What is the practical impact of a successful trigger?
A peer can exhaust the L2CAP signaling identifier range by causing repeated LE credit packets. Subsequent credit packets use invalid identifier 0, so validating remote stacks discard them and the LE CoC channel stalls permanently; with default socket buffers, this occurs after roughly 0.5 MB of received data.
How can an administrator identify that the issue is occurring?
Kernel logs may contain "Bluetooth: Unable to allocate ident: -28". After this message, affected LE CoC channels may stop progressing because remote peers no longer receive valid credit updates.