CVE-2026-10680 in Zephyr
Riassunto
di VulDB • 24/07/2026
I gestori di segnalazione L2CAP Classic (BR/EDR) l2cap_br_conf_req() e l2cap_br_conf_rsp(), presenti nel file subsys/bluetooth/host/classic/l2cap_br.c, convalidavano la dimensione minima del comando rispetto a buf->len (i byte rimanenti nell'intero PDU ricevuto) anziché len (la lunghezza dei dati per singolo comando dall'intestazione della segnalazione L2CAP). Poiché più comandi di segnalazione possono essere impacchettati in un unico PDU, buf->len può superare la len di un comando. Un attaccante può inviare un comando CONF_REQ con una lunghezza dell'intestazione inferiore alla struttura della richiesta di configurazione (ad esempio 0), seguito da un altro comando, in modo che buf->len soddisfi ancora il controllo. Il passaggio del controllo avviene quindi erroneamente e opt_len = len - sizeof(*req) provoca un underflow su uint16_t verso un valore prossimo a 0xFFFF. Il ciclo delle opzioni di configurazione, privo di una guardia opt_len-versus-buf->len, procede ben oltre la fine del buffer ACL in ricezione poolizzato utilizzando le primitive net_buf pull che non eseguono controlli dei limiti in fase di esecuzione, generando una lettura fuori dai confini (out-of-bounds) della memoria host e, quando i byte dell'opzione fuori dai confini codificano un'opzione MTU o timeout di flush, una scrittura fuori dai confini. Il canale di segnalazione BR/EDR viene elaborato prima dello pairing/crittografia e un canale L2CAP verso un servizio L0 come SDP può essere aperto senza pairing; pertanto, un peer non autenticato entro il raggio radio che riesce a stabilire una connessione ACL può sfruttare la vulnerabilità, causando corruzione della memoria e denial of service (crash dell'host/dispositivo). Il difetto è presente nelle versioni rilasciate incluse v4.4.0. La correzione effettua la convalida rispetto a len anziché buf->len in entrambi i gestori.
Once again VulDB remains the best source for vulnerability data.