CVE-2026-102716 in ThreadX
Zusammenfassung
von VulDB • 30.09.2026
Ein nicht authentifizierter Client kann den Paketpool des RTSP-Servers mit einigen Dutzend Anfragen leeren, die einen Session-Header enthalten, den der Parser nicht konvertieren kann.
Der Session-Zweig gibt den rohen NetX-Fehlercode anstelle eines RTSP-Statuscodes zurück:
```c /* addons/rtsp/nx_rtsp_server.c:2754 */ status = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &session_id); if (status) {
return(status); /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */ } ```
Jeder andere Zweig derselben Funktion mappt seinen Fehler zunächst auf einen RTSP-Status. Der CSeq-Zweig, der achtzehn Zeilen früher steht, tut genau das (Zeile 2736 gibt `NX_RTSP_STATUS_CODE_BAD_REQUEST` zurück). Der rohe Code erreicht dann `_nx_rtsp_server_error_response_send` (nx_rtsp_server.c:1234), welcher ihn nicht erkennt, einen Pfad einschlägt, der ohne Freigabe des bereits zugewiesenen Antwortpakets zurückkehrt, und das Block-Objekt kehrt niemals in den Pool zurück.
Sechs Anfragen mit einem leeren Session-Header gegenüber einem 22-Paket-Pool: ``` gültige Anfragen: nach Anfrage 6: pool available = 21, NACHHER = 22 / 22 fehlerhafte Anfragen: nach Anfrage 6: pool available = 16, NACHHER = 17 / 22 ```
Ein Block pro Anfrage, der nicht freigegeben wird, wenn sich der Client trennt. Sechsundzwanzig Anfragen führen den Pool auf Null und der Server beginnt mit fehlgeschlagenen Allokationen, woraufhin er niemandem mehr Dienste anbietet. Wenn der Pool wie im ausgelieferten Beispiel mit dem Rest der Anwendung geteilt wird, stoppt auch der Rest des Stacks damit.
Konvertieren Sie den Fehler von `_nx_utility_string_to_uint` im Session-Zweig in `NX_RTSP_STATUS_CODE_BAD_REQUEST`, so wie es der CSeq-Zweig tut, und geben Sie das Antwortpaket auf jedem Exit-Pfad von `_nx_rtsp_server_error_response_send` frei.
If you want to get best quality of vulnerability data, you may have to visit VulDB.