CVE-2026-81038: Bluetooth OTS server discloses uninitialized stack memory in failed Calculate Checksum responses
The Object Transfer Service server builds its Object Action Control Point (OACP) response indication in oacpindsend() (subsys/bluetooth/services/ots/otsoacp.c). Before this fix the four-byte Checksum Value field was appended whenever the requested op code was BTGATTOTSOACPPROCCHECKSUMCALC, regardless of the result code. The response payload is a bare, uninitialized four-byte stack buffer declared with NETBUFSIMPLEDEFINE(respparam, sizeof(uint32t)) in btgattotsoacpwrite(), and it is filled only on the success path of oacpchecksumprocvalidate(). On every failure path the buffer is still empty, so netbufsimplepullle32() was invoked on a zero-length buffer.
The OACP characteristic and its client characteristic configuration descriptor are declared with BTGATTPERMWRITE and BTGATTPERMREAD | BTGATTPERMWRITE, so no pairing, encryption, or authentication is required. Any peer within radio range that can connect to a device running the OTS server can enable OACP indications and write a nine-byte Calculate Checksum command that fails validation — for example by issuing it with no object selected, which returns BTGATTOTSOACPRESINVOBJ. Because oacpcommanddecode() accepts the Calculate Checksum op code unconditionally (it is not guarded by CONFIGBTOTSOACPCHECKSUMSUPPORT), builds without checksum support are reachable too: they answer BTGATTOTSOACPRESOPCODENOTSUP and take the same bad path.
On builds with CONFIGASSERT enabled, the zero-length pull trips the assertion inside netbufsimplepullmem() and panics the device, giving a remotely triggered denial of service. On builds with assertions disabled there is no check: the pull returns the untouched stack array and four bytes of uninitialized stack memory are copied into the indication and transmitted to the peer, repeatable on every request. The disclosure is bounded to four bytes per request and the write stays inside the seven-byte res indication buffer, so there is no memory corruption; the impact is uninitialized-memory disclosure plus an availability loss in assertion-enabled configurations.
Affected Software
Event History
Frequently Asked Questions
Who can reach the vulnerable service?
Any Bluetooth peer within radio range that can connect to a device running the OTS server can reach it. The affected OACP characteristic permits writes, and its client configuration descriptor permits reads and writes.
Does exploitation require pairing or authentication?
No. The described permissions do not require pairing, encryption, or authentication.
What does an attacker need to send to trigger the issue?
The attacker must enable OACP indications and submit a nine-byte Calculate Checksum command that fails validation. One stated trigger is issuing the command when no object is selected, which returns an invalid-object result.