CVE-2026-102716

An unauthenticated client can drain the RTSP servers packet pool with a couple of dozen requests

that carry a Session header the parser cannot convert.

The Session branch returns the raw NetX error code instead of an RTSP status code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

/* 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 */


}

Every other branch of the same function maps its failure to an RTSP status first. The CSeq branch

eighteen lines earlier does exactly that (line 2736 returns NX_RTSP_STATUS_CODE_BAD_REQUEST). The

raw code then reaches _nx_rtsp_server_error_response_send (nx_rtsp_server.c:1234), which does not

recognise it, takes a path that returns without releasing the response packet it already allocated,

and the block never goes back to the pool.

Six requests with an empty Session header against a 22 packet pool:

1
2
3
4
5
6
7
8

valid requests:      after request 6: pool available = 21,  AFTER = 22 / 22



malformed requests:  after request 6: pool available = 16,  AFTER = 17 / 22

One block per request, not returned when the client disconnects. Twenty six requests take the pool

to zero and the server starts failing allocations, after which it serves nobody. If the pool is

shared with the rest of the application, as it is in the shipped sample, the rest of the stack

stops with it.

Convert the _nx_utility_string_to_uint failure in the Session branch into

NX_RTSP_STATUS_CODE_BAD_REQUEST the way the CSeq branch does, and release the response packet on

every exit path of _nx_rtsp_server_error_response_send.

Weakness

The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

Potential Mitigations

• Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.
• For example, glibc in Linux provides protection against free of invalid pointers.
• When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].
• To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.

References

• https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-q462-246c-x3jc