CVE-2026-82389 json
Bluetooth Classic HFP AG wipes an object still linked in the SDP request list on connect failure, causing a NULL dereference
published 16d ago modified 8d ago also EUVD-2026-109975 , GHSA-rrqj-542q-26jm
Unreviewed: the maintainers' own advisory
Published by the maintainers on their GitHub repository zephyrproject-rtos/zephyr. GitHub has not reviewed it into the GitHub Advisory Database, so the affected packages and versions are the maintainers' word. Read the full advisory on GitHub.
- cvss
- 6.5
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 14%
- public exploits
- 0
- none known
Summary
In the Bluetooth Classic Hands-Free Profile Audio Gateway role, hfp_ag_create() in subsys/bluetooth/host/classic/hfp_ag.c starts an SDP discovery toward the peer, which links the embedded ag->sdp_param._node into the SDP client's pending request list in subsys/bluetooth/host/classic/sdp.c. If the subsequent bt_rfcomm_dlc_connect() call fails, bt_hfp_ag_connect() cleaned up by memset()-ing the entire AG object while that node was still linked, and while ag->slc_work could still be queued on the system work queue. An in-flight SDP discovery cannot be cancelled — bt_sdp_discover_cancel() is declared in the public header but has no implementation — so the request stays in the list with its func, pool and uuid pointers zeroed.
The RFCOMM channel passed to bt_hfp_ag_connect() is taken from the peer's own SDP Hands-Free service record in the normal AG flow (bt_sdp_get_proto_param() performs no range validation, and samples/bluetooth/classic/handsfree_ag feeds the value straight through), so a remote BR/EDR device in radio range that advertises an RFCOMM channel outside the valid range 0x01..0x1e deterministically forces bt_rfcomm_dlc_connect() to fail and reach the wipe. Reading the peer's SDP record requires no pairing, and the peer can also trigger the failure by dropping the ACL or racing an RFCOMM DLC on the same DLCI at the right moment.
When the SDP client next advances its request list, sdp_client_discover() dereferences the zeroed parameters — net_buf_alloc(param->pool, …) with a NULL pool and param->uuid->type — and the result-notification paths call through the NULL params->func. Zeroing a linked node also truncates the request list behind a stale tail pointer, and re-arming the freed AG slot re-appends the same node and can produce a self-looping list that hangs the Bluetooth RX thread. The impact is a crash or hang of the Bluetooth stack; the written value is a constant zero at a fixed static address, so no attacker-controlled write is available.
Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_AG that use the Audio Gateway role are affected.
Patch / fix
Is CVE-2026-82389 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCISA SSVC
- Exploitation
- none
- Automatable
- no
- Technical impact
- partial
- Assessed
- 16d ago
Exploit prediction
0.23% chance of exploitation in the next 30 days, higher than 14% of all scored CVEs (FIRST EPSS, 2026-11-11).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 6.5 | CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
Affected products
- zephyrproject zephyr
Classification
- Weakness
-
- CWE-476 NULL Pointer Dereference
References
Sources
- CVE List CVE-2026-82389
- NVD CVE-2026-82389
- Maintainer advisory GHSA-rrqj-542q-26jm
Fencer Intel 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.
The maintainers of zephyrproject-rtos/zephyr published their own advisory on GitHub. Reviewed sources take precedence over it.