CVE-2026-80760: Bluetooth: MGMT: reject HCI_CMD_SYNC params_len above 255
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: reject HCICMDSYNC paramslen above 255
mgmthcicmdsync() checks that the message length agrees with paramslen but puts no upper bound on it. paramslen is le16 while the parameter length in the HCI command header is a u8:
struct hcicommandhdr { le16 opcode; u8 plen; } packed;
hcicmdsyncalloc() assigns one to the other:
hdr->plen = plen;
if (plen) skbputdata(skb, param, plen);
so a paramslen of 256 leaves plen at 0 while all 256 bytes are still appended. The frame handed to the driver then declares no parameters and carries 256 of them. On a length framed transport such as H:4 the controller takes the trailing bytes as the start of the next packet.
The mgmt socket MTU is HCIMAXFRAMESIZE, so paramslen can reach about 1KB this way. Commit 03f1700b9b4d ("Bluetooth: MGMT: reject malformed HCICMDSYNC commands") only made paramslen agree with the message length, a value that fits the message but not the header field is still accepted.
Reject paramslen that does not fit the header field.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel Bluetooth MGMT (HCI_CMD_SYNC malformed params_len length framed transport)to a version that resolves this vulnerability.Patch 03f1700b9b4d
Event History
Frequently Asked Questions
What parameter lengths trigger the malformed command condition?
A HCI_CMD_SYNC request with params_len greater than 255 triggers it. The 16-bit params_len value is truncated when assigned to the 8-bit HCI header plen field, while the full parameter data is still appended.
What happens when params_len is 256?
The HCI command header declares a parameter length of zero, but 256 parameter bytes are included in the frame. On length-framed transports such as H:4, the controller can interpret those trailing bytes as the beginning of the next packet.
Does validating that the message length matches params_len prevent this?
No. The earlier validation only ensures that params_len matches the supplied message length; it does not ensure that params_len fits in the one-byte HCI command-header length field. The resolved change rejects params_len values that do not fit that field.