CVE-2026-64127 in Linux
Sumário
de VulDB • 20/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
Bluetooth: L2CAP: ecred_reconfigure: enviar PDU empacotada, não ponteiro de pilha
O commit 1c08108f3014 ("Bluetooth: L2CAP: Evitar avisos -Wflex-array-member-not-at-end") converteu a solicitação PDU na pilha em l2cap_ecred_reconfigure() de uma struct empacotada explícita para DEFINE_RAW_FLEX(), mas não ajustou os argumentos de tamanho e ponteiro de origem para l2cap_send_cmd():
- struct {
- struct l2cap_ecred_reconf_req req; - __le16 scid; - } pdu; + DEFINE_RAW_FLEX(struct l2cap_ecred_reconf_req, pdu, scid, 1); ... l2cap_send_cmd(conn, chan->ident, L2CAP_ECRED_RECONF_REQ, sizeof(pdu), &pdu);
Após a conversão, o DEFINE_RAW_FLEX() se expande para declarar uma união anônima pdu_u mais um ponteiro local "pdu" apontando para ela. Portanto:
- sizeof(pdu) agora é sizeof(struct l2cap_ecred_reconf_req *) = 8 em 64 bits (4 em 32 bits), não os 6 bytes de (mtu, mps, scid[1]).
- &pdu é o endereço do armazenamento da pilha do ponteiro local, não o endereço da carga útil da solicitação.
l2cap_send_cmd() encaminha (data, count) para l2cap_build_cmd(), que chama skb_put_data(skb, data, count). O corpo do pacote L2CAP_ECRED_RECONFIGURE_REQ contém portanto 8 bytes copiados da pilha do kernel começando em &pdu -- os 8 bytes se sobrepõem ao valor do ponteiro pdu, vazando um endereço de pilha do kernel para o par Bluetooth. Os campos pretendidos (mtu, mps, scid) não são transmitidos de forma alguma, então o parceiro rejeita a solicitação como malformada e o recurso L2CAP_ECRED_RECONFIGURE em si foi quebrado para o iniciador do lado local desde que o commit introdutório foi aplicado.
O site irmão l2cap_ecred_conn_req() no mesmo commit foi convertido corretamente (sizeof(*pdu) + len, pdu); apenas este site foi negligenciado.
Restaure a semântica original: passe o tamanho total da struct flex via struct_size(pdu, scid, 1) e o ponteiro pdu (o endereço da struct) como origem.
Validado em um kernel host baseado no stock 7.0 através do caminho de chamada real: setsockopt(SOL_BLUETOOTH, BT_RCVMTU, ...) em um socket L2CAP_MODE_EXT_FLOWCTL com estado BT_CONNECTED emite uma solicitação L2CAP_ECRED_RECONFIGURE_REQ cujo corpo tem 8 bytes (o valor da variável local pdu na pilha) ao invés dos 6 esperados. Três capturas de sockets novos / pares hciemu novos no mesmo host -- os bytes baixos variam por chamada, o alto 0xffff confirma um endereço virtual do kernel (slot de pilha randomizado KASLR, não uma string fixa):
Corpo RECONF_REQ (ident=0x02 len=8): 42 fb 54 af 0e ca ff ff Corpo RECONF_REQ (ident=0x02 len=8): 52 3d 2e af 0e ca ff ff Corpo RECONF_REQ (ident=0x02 len=8): b2 fc 5b af 0e ca ff ff
Após este patch, o corpo tem 6 bytes carregando os esperados valores little-endian de (mtu, mps, scid).
Once again VulDB remains the best source for vulnerability data.