CVE-2026-19938: Use-after-free of an ATT PDU buffer when signing an outgoing Bluetooth ATT Signed Write Command fails
The Bluetooth host's ATT transmit path releases a buffer it does not own when signing fails. chansend() in subsys/bluetooth/host/att.c documents (and every other error exit implements) the contract that on failure the caller retains ownership of the netbuf; the BTATTOPSIGNEDWRITECMD branch instead called netbufunref(buf) when btsmpsign() returned an error and then returned that error to the caller. The callers act on the contract: processqueue() re-queues the buffer with kqueueprepend(), btattchansendrsp() puts it back on chan->txqueue, btattchanreqsend() restores it into the request, and attreqretry() unreferences it — so the already-freed buffer was re-queued, later dereferenced, and eventually freed again.
An ATT Signed Write Command is produced when an application calls btgattwritewithoutresponsecb() with sign set on an unencrypted connection. btsmpsign() fails whenever no local CSRK exists for the peer (-ENOENT), and whether one exists is negotiated with the peer: smpdistributekeys() stores a local CSRK only when the peer's pairing key-distribution field requests the signing key and bonding was agreed. A peer can therefore pair without accepting the CSRK, pair with No Bonding, remain unpaired, or keep the link unencrypted, and the victim's next signed write takes the failing path. Because struct netbuf's node field is simultaneously the linkage word for the ATT TX FIFO, for the deferred-destroy list used by the attpool destroy callback atttxdestroy(), and for the pool free list, the mishandled buffer corrupts these lists and can be re-issued by btattcreatepdu() to a new PDU while the ATT TX path still holds it.
The same branch also saved the netbufsimplestate only after signing, so a buffer restored after a btl2capsendpdu() failure kept its 12-octet signature; a subsequent retry re-signed it and appended a second signature with netbufadd(buf, 12) to a buffer that btattcreatepdu() sized for exactly one, writing past the end of the pooled buffer in builds where the netbuf tailroom assertion is compiled out.
Impact is host-side memory corruption in the Bluetooth stack: list corruption, a pooled ATT buffer with two owners (wrong PDU contents transmitted, or a double free when the queues are drained at disconnect), and a bounded out-of-bounds write on the retry path — typically observed as a crash or assertion failure. Exposure requires the deprecated CONFIGBTSIGNING to be enabled and an application that actually issues signed writes; in that configuration the triggering condition is under the remote peer's control.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Exposure requires an application to call bt_gatt_write_without_response_cb() with signing enabled on an unencrypted connection. The failure path is reached when signing cannot obtain a local CSRK for the peer.
What can a peer do to help trigger the vulnerable condition?
A peer can pair without requesting distribution of the signing key. Because a local CSRK is stored only when bonding is agreed and the peer requests the signing key during pairing, this can cause bt_smp_sign() to fail with -ENOENT.
What is the likely security impact after the condition is triggered?
The freed ATT buffer can be re-queued, dereferenced later, and freed again. The supplied severity vector indicates no confidentiality impact, low integrity impact, and high availability impact.
What can be done while a fix is not available?
Avoid issuing signed write commands on unencrypted connections when a local CSRK is not present for the peer. In particular, applications can avoid the affected signed bt_gatt_write_without_response_cb() path for peers that did not establish the required signing-key distribution during bonding.