CVE-2026-77685: Bluetooth Classic RFCOMM: integer underflow in the MCC TEST command handler leads to out-of-bounds read disclosed to the peer and out-of-bounds write

The RFCOMM multiplexer control-channel handler in subsys/bluetooth/host/classic/rfcomm.c computed the echo length for a BTRFCOMMTEST command as buf->len - 1 and passed it to rfcommsendtest(), whose length parameter is a uint8t. A malformed but FCS-valid UIH frame on DLCI 0 can leave buf->len == 0 after rfcommhandlemsg() pulls the two-byte MCC header, so buf->len - 1 underflows and narrows to 255.

rfcommsendtest() then copies 255 bytes out of a receive buffer that holds no remaining valid data, and appends them to an outgoing L2CAP PDU allocated with only CONFIGBTL2CAPTXMTU (253 by default for CONFIGBTCLASSIC) bytes of tailroom. The source read runs past the end of the ACL receive buffer into adjacent buffers of the same netbuf pool, and the destination copy overruns the transmit buffer by about eight bytes; netbufaddmem() performs no runtime bounds check in ordinary builds, where the underlying ASSERTNOMSG() is compiled out.

The trigger is a single five-byte RFCOMM frame on the multiplexer control channel, which is processed as soon as the L2CAP channel for PSM 3 is established — before any DLC exists and independent of RFCOMM session state. btrfcomminit() registers that L2CAP server with .seclevel = BTSECURITYL1, which l2capbrconnsecurity() accepts without any link key from a peer that does not claim host Secure Simple Pairing support, so an unpaired BR/EDR device in radio range of a connectable target with CONFIGBTRFCOMM enabled (SPP, HFP, HSP, GOEP and similar profiles all enable it) can reach the defect.

The resulting 255-byte TEST response is transmitted back to the attacker, disclosing roughly 255 bytes of adjacent stack/pool memory — including the contents of neighbouring receive buffers, which an attacker can prime with earlier packets — and the accompanying out-of-bounds write corrupts memory following the transmit buffer, which can crash the Bluetooth host. The request is trivially repeatable, so both the disclosure and the corruption can be driven at will.

Two fixes are needed, and the first on its own does not close the out-of-bounds write. Fix 1 (0040ef781e1d, #115768) strips the FCS byte in rfcommrecv() and echoes buf->len, rejecting anything over UINT8MAX, which removes the underflow and the over-read. But rfcommmakeuihmsg() still allocates the response with btl2capcreatepdu() and never compares the requested length with the buffer's tailroom, so a well-formed TEST command carrying a pattern of about 248 bytes or more still builds a response (3-byte frame header, 2-byte message header, pattern, FCS) larger than the 253 bytes available. A pattern that long can only be received when the RFCOMM L2CAP receive MTU (CONFIGBTRFCOMML2CAPMTU, which defaults to CONFIGBTBUFACLRXSIZE) exceeds CONFIGBTL2CAPTXMTU. The plain BR/EDR defaults (200 against 253) cannot reach it, but from v4.3.0 enabling CONFIGBTGOEP raises CONFIGBTBUFACLRXSIZE to 264 (265 from v4.4.0), so GOEP builds with only fix 1 applied still overrun the transmit buffer by up to eight bytes. This includes v4.3.2, the last v4.3 release, which carries fix 1 but will not receive fix 2. Fix 2 (214530895dd3, #118293) checks the tailroom on every RFCOMM PDU allocation and closes this residual write.