Bluetooth: L2CAP: fix tx ident leak for commands without a response
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 wa
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.18.40, 7.1.5
- CVEs
- CVE-2026-72333
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 28 Oct 2026, 08:57 UTC · Revision 1
Source evidence
Bluetooth: L2CAP: fix tx ident leak for commands without a response
core-osv · Original sourcePublished 15 Aug 2026, 05:55 UTC
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 wa
osv:CVE-2026-72333
Kernel
Fixed versions: 6.18.40, 7.1.5
Complete source record
{
"id": "b229911c4ee4659cc7ebb3ec5fe753409ec1c033d2463ef61ad9b7796f1eee2a",
"url": "https://osv.dev/vulnerability/CVE-2026-72333",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Bluetooth: L2CAP: fix tx ident leak for commands without a response",
"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 wa",
"evidence": "osv:CVE-2026-72333",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.18.40",
"evidence": "/affected/1/ranges"
},
{
"value": "7.1.5",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-72333",
"aliases": [
"CVE-2026-72333"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "e86554c37d3d2b4b24608e0313f882cae28b8adb"
},
{
"fixed": "b8a32a5fc915b024c60f18d51b6cffd2bd64d4a6"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "9b24ad4787cad46a3917620799f8455c6533b8df"
},
{
"fixed": "bd1e01170341291292fd4c46b5f6949da282ca6c"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "ea6cf86167b3972caa68972d2a1ad43ecbbb8331"
},
{
"fixed": "0c602cb8f148a36bfb39c25ade400bdadc023c4f"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6c3ea155e5ee3e56606233acde8309afda66d483"
},
{
"fixed": "d0a2b0c81f112540a337cde1c20251bf05ddf1da"
},
{
"fixed": "6e1930ece855a4c256f1c7e6632d634cfb9888b5"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.18.21"
},
{
"fixed": "6.18.40"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "5.10.261"
},
{
"fixed": "5.11"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "5.15.212"
},
{
"fixed": "5.16"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.19.11"
},
{
"fixed": "6.20"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "ed97bb2cf96684ee646be6f37e4c4835f9d30caa"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "84bc3197f7d87c5b89c156e853d0561a9154eceb"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "8c1cdbc1bacc0cf9c27c3ebda11a81c3dcd01630"
}
]
}
],
"versions": [
"v6.18.39",
"v6.18.38",
"v6.18.37",
"v6.18.36",
"v6.18.35",
"v6.18.34",
"v6.18.33",
"v6.18.32",
"v6.18.31",
"v6.18.30",
"v6.18.29",
"v6.18.28",
"v6.18.27",
"v6.18.26",
"v6.18.25",
"v6.18.24",
"v6.18.23",
"v6.18.22",
"v6.18.21",
"v5.10.271",
"v5.10.270",
"v5.10.269",
"v5.10.268",
"v5.10.267",
"v5.10.266",
"v5.10.265",
"v5.10.264",
"v5.10.263",
"v5.10.262",
"v5.10.261",
"v5.15.222",
"v5.15.221",
"v5.15.220",
"v5.15.219",
"v5.15.218",
"v5.15.217",
"v5.15.216",
"v5.15.215",
"v5.15.214",
"v5.15.213",
"v5.15.212",
"v6.19.14",
"v6.19.13",
"v6.19.12",
"v6.19.11"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72333.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "6.18.40"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.1.5"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72333.json"
}
}
],
"modified": "2026-10-08T02:51:47.752395137Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/0c602cb8f148a36bfb39c25ade400bdadc023c4f",
"https://git.kernel.org/stable/c/6e1930ece855a4c256f1c7e6632d634cfb9888b5",
"https://git.kernel.org/stable/c/b8a32a5fc915b024c60f18d51b6cffd2bd64d4a6",
"https://git.kernel.org/stable/c/bd1e01170341291292fd4c46b5f6949da282ca6c",
"https://git.kernel.org/stable/c/d0a2b0c81f112540a337cde1c20251bf05ddf1da",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72333.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-72333",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72333.json"
}
},
"related_cves": [
{
"value": "CVE-2026-72333",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 98346,
"published_at": "2026-08-15T05:55:42.523+00:00"
}