An unauthenticated client can drain the RTSP server's 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:
```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 */}
```
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:
```
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`.
"}],"value":"An unauthenticated client can drain the RTSP server's packet pool with a couple of dozen requests\n\n\n\nthat carry a Session header the parser cannot convert.\n\n\n\nThe Session branch returns the raw NetX error code instead of an RTSP status code:\n\n\n\n```c\n\n\n\n/* addons/rtsp/nx_rtsp_server.c:2754 */\n\n\n\nstatus = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &session_id);\n\n\n\nif (status)\n\n\n\n{\n\n return(status); /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */\n\n\n}\n\n\n\n```\n\n\n\nEvery other branch of the same function maps its failure to an RTSP status first. The CSeq branch\n\n\n\neighteen lines earlier does exactly that (line 2736 returns NX_RTSP_STATUS_CODE_BAD_REQUEST). The\n\n\n\nraw code then reaches `_nx_rtsp_server_error_response_send` (nx_rtsp_server.c:1234), which does not\n\n\n\nrecognise it, takes a path that returns without releasing the response packet it already allocated,\n\n\n\nand the block never goes back to the pool.\n\n\n\nSix requests with an empty Session header against a 22 packet pool:\n\n\n\n```\n\n\n\nvalid requests: after request 6: pool available = 21, AFTER = 22 / 22\n\n\n\nmalformed requests: after request 6: pool available = 16, AFTER = 17 / 22\n\n\n\n```\n\n\n\nOne block per request, not returned when the client disconnects. Twenty six requests take the pool\n\n\n\nto zero and the server starts failing allocations, after which it serves nobody. If the pool is\n\n\n\nshared with the rest of the application, as it is in the shipped sample, the rest of the stack\n\n\n\nstops with it.\n\n\n\nConvert the `_nx_utility_string_to_uint` failure in the Session branch into\n\n\n\nNX_RTSP_STATUS_CODE_BAD_REQUEST the way the CSeq branch does, and release the response packet on\n\n\n\nevery exit path of `_nx_rtsp_server_error_response_send`."}],"metrics":[{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"LOW","attackRequirements":"NONE","attackVector":"NETWORK","baseScore":8.7,"baseSeverity":"HIGH","exploitMaturity":"NOT_DEFINED","privilegesRequired":"NONE","providerUrgency":"NOT_DEFINED","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","version":"4.0","vulnAvailabilityImpact":"HIGH","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-401","description":"CWE-401 Missing Release of Memory after Effective Lifetime","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-09-29T17:43:55.870Z","orgId":"e51fbebd-6053-4e49-959f-1b94eeb69a2c","shortName":"eclipse"},"references":[{"url":"https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-q462-246c-x3jc"}],"source":{"discovery":"UNKNOWN"},"x_generator":{"engine":"Vulnogram 1.0.5"}}},"cveMetadata":{"assignerOrgId":"e51fbebd-6053-4e49-959f-1b94eeb69a2c","assignerShortName":"eclipse","cveId":"CVE-2026-102716","datePublished":"2026-09-29T17:43:55.870Z","dateReserved":"2026-09-29T16:15:12.001Z","dateUpdated":"2026-09-29T18:41:10.594Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-29 18:17:10","lastModifiedDate":"2026-09-29 19:17:20","problem_types":["CWE-401","CWE-401 CWE-401 Missing Release of Memory after Effective Lifetime"],"metrics":{"cvssMetricV40":[{"source":"emo@eclipse.org","type":"Secondary","cvssData":{"version":"4.0","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","baseScore":8.7,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"NONE","userInteraction":"NONE","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}}],"ssvcV203":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2026-09-29T18:40:53.878601Z","id":"CVE-2026-102716","options":[{"exploitation":"none"},{"automatable":"yes"},{"technicalImpact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"102716","Ordinal":"1","Title":"CVE-2026-102716","CVE":"CVE-2026-102716","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"102716","Ordinal":"1","NoteData":"An unauthenticated client can drain the RTSP server's packet pool with a couple of dozen requests\n\n\n\nthat carry a Session header the parser cannot convert.\n\n\n\nThe Session branch returns the raw NetX error code instead of an RTSP status code:\n\n\n\n```c\n\n\n\n/* addons/rtsp/nx_rtsp_server.c:2754 */\n\n\n\nstatus = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &session_id);\n\n\n\nif (status)\n\n\n\n{\n\n return(status); /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */\n\n\n}\n\n\n\n```\n\n\n\nEvery other branch of the same function maps its failure to an RTSP status first. The CSeq branch\n\n\n\neighteen lines earlier does exactly that (line 2736 returns NX_RTSP_STATUS_CODE_BAD_REQUEST). The\n\n\n\nraw code then reaches `_nx_rtsp_server_error_response_send` (nx_rtsp_server.c:1234), which does not\n\n\n\nrecognise it, takes a path that returns without releasing the response packet it already allocated,\n\n\n\nand the block never goes back to the pool.\n\n\n\nSix requests with an empty Session header against a 22 packet pool:\n\n\n\n```\n\n\n\nvalid requests: after request 6: pool available = 21, AFTER = 22 / 22\n\n\n\nmalformed requests: after request 6: pool available = 16, AFTER = 17 / 22\n\n\n\n```\n\n\n\nOne block per request, not returned when the client disconnects. Twenty six requests take the pool\n\n\n\nto zero and the server starts failing allocations, after which it serves nobody. If the pool is\n\n\n\nshared with the rest of the application, as it is in the shipped sample, the rest of the stack\n\n\n\nstops with it.\n\n\n\nConvert the `_nx_utility_string_to_uint` failure in the Session branch into\n\n\n\nNX_RTSP_STATUS_CODE_BAD_REQUEST the way the CSeq branch does, and release the response packet on\n\n\n\nevery exit path of `_nx_rtsp_server_error_response_send`.","Type":"Description","Title":"CVE-2026-102716"}]}}}