<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 19:39:17 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-102716</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-102716</link>
      <description>&lt;p&gt;An unauthenticated client can drain the RTSP server&amp;#39;s packet pool with a couple of dozen requests&lt;/p&gt;
&lt;p&gt;that carry a Session header the parser cannot convert.&lt;/p&gt;
&lt;p&gt;The Session branch returns the raw NetX error code instead of an RTSP status code:&lt;/p&gt;
&lt;p&gt;```c&lt;/p&gt;
&lt;p&gt;/* addons/rtsp/nx_rtsp_server.c:2754 */&lt;/p&gt;
&lt;p&gt;status = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &amp;amp;session_id);&lt;/p&gt;
&lt;p&gt;if (status)&lt;/p&gt;
&lt;p&gt;{&lt;/p&gt;
&lt;p&gt;return(status);      /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */&lt;/p&gt;
&lt;p&gt;}&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;Every other branch of the same function maps its failure to an RTSP status first. The CSeq branch&lt;/p&gt;
&lt;p&gt;eighteen lines earlier does exactly that (line 2736 returns NX_RTSP_STATUS_CODE_BAD_REQUEST). The&lt;/p&gt;
&lt;p&gt;raw code then reaches `_nx_rtsp_server_error_response_send` (nx_rtsp_server.c:1234), which does not&lt;/p&gt;
&lt;p&gt;recognise it, takes a path that returns without releasing the response packet it already allocated,&lt;/p&gt;
&lt;p&gt;and the block never goes back to the pool.&lt;/p&gt;
&lt;p&gt;Six requests with an empty Session header against a 22 packet pool:&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;valid requests:      after request 6: pool available = 21,  AFTER = 22 / 22&lt;/p&gt;
&lt;p&gt;malformed requests:  after request 6: pool available = 16,  AFTER = 17 / 22&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;One block per request, not returned when the client disconnects. Twenty six requests take the pool&lt;/p&gt;
&lt;p&gt;to zero and the server starts failing allocations, after which it serves nobody. If the pool is&lt;/p&gt;
&lt;p&gt;shared with the rest of the application, as it is in the shipped sample, the rest of the stack&lt;/p&gt;
&lt;p&gt;st…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;An unauthenticated client can drain the RTSP server&amp;#39;s packet pool with a couple of dozen requests&lt;/p&gt;
&lt;p&gt;that carry a Session header the parser cannot convert.&lt;/p&gt;
&lt;p&gt;The Session branch returns the raw NetX error code instead of an RTSP status code:&lt;/p&gt;
&lt;p&gt;```c&lt;/p&gt;
&lt;p&gt;/* addons/rtsp/nx_rtsp_server.c:2754 */&lt;/p&gt;
&lt;p&gt;status = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &amp;amp;session_id);&lt;/p&gt;
&lt;p&gt;if (status)&lt;/p&gt;
&lt;p&gt;{&lt;/p&gt;
&lt;p&gt;return(status);      /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */&lt;/p&gt;
&lt;p&gt;}&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;Every other branch of the same function maps its failure to an RTSP status first. The CSeq branch&lt;/p&gt;
&lt;p&gt;eighteen lines earlier does exactly that (line 2736 returns NX_RTSP_STATUS_CODE_BAD_REQUEST). The&lt;/p&gt;
&lt;p&gt;raw code then reaches `_nx_rtsp_server_error_response_send` (nx_rtsp_server.c:1234), which does not&lt;/p&gt;
&lt;p&gt;recognise it, takes a path that returns without releasing the response packet it already allocated,&lt;/p&gt;
&lt;p&gt;and the block never goes back to the pool.&lt;/p&gt;
&lt;p&gt;Six requests with an empty Session header against a 22 packet pool:&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;valid requests:      after request 6: pool available = 21,  AFTER = 22 / 22&lt;/p&gt;
&lt;p&gt;malformed requests:  after request 6: pool available = 16,  AFTER = 17 / 22&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;One block per request, not returned when the client disconnects. Twenty six requests take the pool&lt;/p&gt;
&lt;p&gt;to zero and the server starts failing allocations, after which it serves nobody. If the pool is&lt;/p&gt;
&lt;p&gt;shared with the rest of the application, as it is in the shipped sample, the rest of the stack&lt;/p&gt;
&lt;p&gt;st…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-102716</guid>
    </item>
    <item>
      <title>GHSA-4637-2x4v-2wq5</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-4637-2x4v-2wq5</link>
      <description>&lt;p&gt;An unauthenticated client can drain the RTSP server&amp;#39;s packet pool with a couple of dozen requests&lt;/p&gt;
&lt;p&gt;that carry a Session header the parser cannot convert.&lt;/p&gt;
&lt;p&gt;The Session branch returns the raw NetX error code instead of an RTSP status code:&lt;/p&gt;
&lt;p&gt;```c&lt;/p&gt;
&lt;p&gt;/* addons/rtsp/nx_rtsp_server.c:2754 */&lt;/p&gt;
&lt;p&gt;status = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &amp;amp;session_id);&lt;/p&gt;
&lt;p&gt;if (status)&lt;/p&gt;
&lt;p&gt;{&lt;/p&gt;
&lt;p&gt;return(status);      /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */&lt;/p&gt;
&lt;p&gt;}&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;Every other branch of the same function maps its failure to an RTSP status first. The CSeq branch&lt;/p&gt;
&lt;p&gt;eighteen lines earlier does exactly that (line 2736 returns NX_RTSP_STATUS_CODE_BAD_REQUEST). The&lt;/p&gt;
&lt;p&gt;raw code then reaches `_nx_rtsp_server_error_response_send` (nx_rtsp_server.c:1234), which does not&lt;/p&gt;
&lt;p&gt;recognise it, takes a path that returns without releasing the response packet it already allocated,&lt;/p&gt;
&lt;p&gt;and the block never goes back to the pool.&lt;/p&gt;
&lt;p&gt;Six requests with an empty Session header against a 22 packet pool:&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;valid requests:      after request 6: pool available = 21,  AFTER = 22 / 22&lt;/p&gt;
&lt;p&gt;malformed requests:  after request 6: pool available = 16,  AFTER = 17 / 22&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;One block per request, not returned when the client disconnects. Twenty six requests take the pool&lt;/p&gt;
&lt;p&gt;to zero and the server starts failing allocations, after which it serves nobody. If the pool is&lt;/p&gt;
&lt;p&gt;shared with the rest of the application, as it is in the shipped sample, the rest of the stack&lt;/p&gt;
&lt;p&gt;st…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;An unauthenticated client can drain the RTSP server&amp;#39;s packet pool with a couple of dozen requests&lt;/p&gt;
&lt;p&gt;that carry a Session header the parser cannot convert.&lt;/p&gt;
&lt;p&gt;The Session branch returns the raw NetX error code instead of an RTSP status code:&lt;/p&gt;
&lt;p&gt;```c&lt;/p&gt;
&lt;p&gt;/* addons/rtsp/nx_rtsp_server.c:2754 */&lt;/p&gt;
&lt;p&gt;status = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &amp;amp;session_id);&lt;/p&gt;
&lt;p&gt;if (status)&lt;/p&gt;
&lt;p&gt;{&lt;/p&gt;
&lt;p&gt;return(status);      /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */&lt;/p&gt;
&lt;p&gt;}&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;Every other branch of the same function maps its failure to an RTSP status first. The CSeq branch&lt;/p&gt;
&lt;p&gt;eighteen lines earlier does exactly that (line 2736 returns NX_RTSP_STATUS_CODE_BAD_REQUEST). The&lt;/p&gt;
&lt;p&gt;raw code then reaches `_nx_rtsp_server_error_response_send` (nx_rtsp_server.c:1234), which does not&lt;/p&gt;
&lt;p&gt;recognise it, takes a path that returns without releasing the response packet it already allocated,&lt;/p&gt;
&lt;p&gt;and the block never goes back to the pool.&lt;/p&gt;
&lt;p&gt;Six requests with an empty Session header against a 22 packet pool:&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;valid requests:      after request 6: pool available = 21,  AFTER = 22 / 22&lt;/p&gt;
&lt;p&gt;malformed requests:  after request 6: pool available = 16,  AFTER = 17 / 22&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;One block per request, not returned when the client disconnects. Twenty six requests take the pool&lt;/p&gt;
&lt;p&gt;to zero and the server starts failing allocations, after which it serves nobody. If the pool is&lt;/p&gt;
&lt;p&gt;shared with the rest of the application, as it is in the shipped sample, the rest of the stack&lt;/p&gt;
&lt;p&gt;st…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-4637-2x4v-2wq5</guid>
    </item>
  </channel>
</rss>
