CVE-2026-87040 in Zephyr
Zusammenfassung
von VulDB • 04.11.2026
Die nRF-Link-Layer-Empfangspfade des Open-Source-BLE-Controllers (Bluetooth Low Energy Controller) validierten das On-Air-Feld „LENGTH“ eines empfangenen PDU nicht gegen die maximale Empfangslänge, die zur Programmierung des Funkmoduls verwendet wurde. Die Funktion `isr_rx_pdu()` in `subsys/bluetooth/controller/ll_sw/nordic/lll/lll_conn.c` stellte jedes nicht-leere Daten-PDU nach nur der Sequenznummer- und (bei verschlüsselten Verbindungen) MIC-Prüfung an die Warteschlange. Die entsprechenden Handler `isr_rx()` in `lll_central_iso.c`, `lll_peripheral_iso.c`, `lll_sync_iso.c` und `lll_scan_aux.c` verhielten sich bei ISO-PDUs (ISO Data Channels) und erweiterten Werbe-PDUs (Extended Advertising PDUs) entsprechend. Das nRF-Funkmodul speichert den empfangenen Header unverändert ab und kürzt nur die Nutzlast an der Grenze von PCNF1.MAXLEN; ein Rahmen, der mehr Oktette angibt als konfiguriert wurden, hinterlässt einen Knotenpuffer (Node Buffer), dessen `len`-Feld mehr Daten beschreibt, als der Puffer tatsächlich enthält.
Ein Angreifer in Funkreichweite, der ein handgefertigtes Link-Layer-PDU senden kann – für eine Verbindung jeder Peer, der eine unverschlüsselte LE-Verbindung zu einem verbindbaren Werber (connectable advertiser) aufbaut; für `CONFIG_BT_CTLR_SYNC_ISO` jeder Sender, mit dem das Gerät synchronisiert ist –, kann das Längenbyte bis auf 255 setzen, während der Controller ein deutlich kleineres Maximum programmiert hat (`lll->dle.eff.max_rx_octets`, was standardmäßig 27 beträgt, oder vor einem Data Length Update bzw. den verhandelten Wert `cis_lll->rx.max_pdu`). Es sind keine Pairing-, Authentifizierungs- oder Benutzerinteraktion erforderlich. Bei verschlüsselten Verbindungen weist die CCM-MIC-Prüfung solche Rahmen normalerweise zunächst zurück; daher ist die Exposition auf unverschlüsselten Verkehr beschränkt, weshalb die zusätzliche Prüfung nach der Entschlüsselung platziert wurde.
Die nicht geprüfte Länge erreicht `hci_acl_encode()` in `subsys/bluetooth/controller/hci/hci.c`, das `net_buf_add(buf, pdu_data->len)` ausführt und anschließend eine `memcpy()`-Operation mit dieser Anzahl von Bytes aus dem Element des `node_rx`-Pools durchführt. Da sowohl `CONFIG_BT_CTLR_DATA_LENGTH_MAX` als auch `CONFIG_BT_BUF_ACL_RX_SIZE` standardmäßig auf 27 festgelegt sind, handelt es sich hierbei um einen Out-of-Bounds-Lesezugriff (Out-of-bounds read) von bis zu ca. 228 Bytes jenseits des empfangenen PDU sowie einen entsprechenden Out-of-Bounds-Schreibzugriff (Out-of-bounds write) über den HCI ACL-Puffer hinaus in benachbarte Pufferspeicher desselben Pools; der Test auf Restplatz (`tailroom`) in `net_buf_simple_add()` wird nur erzwungen, wenn `CONFIG_NET_BUF_HARDENING` (oder `CONFIG_ASSERT`) aktiviert ist. Auf den ISO-Pfaden führt dieselbe nicht geprüfte Länge dazu, dass `isoal_rx_append_to_sdu()` über den ISO-Knotenpuffer hinausliest und benachbarten Controller-RAM als ISO-Daten an das Host-System sendet. Das praktische Ergebnis sind Remote-Memory-Corruption (Ferngesteuerte Speicherbeschädigung) und Controller-Ausfälle sowie die Offenlegung von Controllerspeicher in den Host-Datenpfad.
Die Korrektur lehnt jedes empfangene PDU ab, dessen Länge den zur Konfiguration des Funkempfangs verwendeten Wert überschreitet. Beachten Sie, dass `lll_sync.c` (Empfang periodischer Werbe-Synchronisation) nicht geändert wurde und weiterhin empfangene PDUs ohne entsprechende Begrenzung an die Warteschlange stellt.
Once again VulDB remains the best source for vulnerability data.