Skip to content
Fencer Vulns
no cvss —

CVE-2026-72333 json

Bluetooth: L2CAP: fix tx ident leak for commands without a response

published 2026-08-15 2 mo ago modified 2026-08-17 2 mo ago also EUVD-2026-59232

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 11%
public exploits
0
none known

Summary

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.

Patch / fix

  • Linux Linux 5.11, 5.16, 6.18.40, 6.20, 7.1.5, 7.2
  • linux Debian 14 7.1.5-1

debian advisories DEBIAN-CVE-2026-72333

  • linux Ubuntu 26.04 LTS 7.0.0-38.38
  • linux-aws Ubuntu 26.04 LTS 7.0.0-1014.14
  • linux-gcp Ubuntu 26.04 LTS 7.0.0-1014.14
  • linux-gke Ubuntu 26.04 LTS 7.0.0-1008.9
  • linux-ibm Ubuntu 26.04 LTS 7.0.0-1015.15
  • linux-azure Ubuntu 26.04 LTS 7.0.0-1017.17
  • linux-riscv Ubuntu 26.04 LTS 7.0.0-38.38.1
  • linux-oracle Ubuntu 26.04 LTS 7.0.0-1013.13

ubuntu advisories UBUNTU-CVE-2026-72333

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-72333 updated cvss 5.5

kernel: Bluetooth: L2CAP: fix tx ident leak for commands without a response

  • Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +82 more Red Hat Enterprise Linux 10 kernel
    affected: no fix available “Fix deferred”
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 kernel-rt, kernel-rt-selftests-internal
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.21% chance of exploitation in the next 30 days, higher than 11% of all scored CVEs (FIRST EPSS, 2026-11-08).

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.