CVE-2026-52986

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_sip: don&amp;#39;t use simple_strtoul<br /> <br /> Replace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(),<br /> and ct_sip_parse_request() with a new sip_parse_port() helper that<br /> validates each digit against the buffer limit, eliminating the use of<br /> simple_strtoul() which assumes NUL-terminated strings.<br /> <br /> The previous code dereferenced pointers without bounds checks after<br /> sip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated<br /> skb data. A port that reaches the buffer limit without a trailing<br /> character is also rejected as malformed.<br /> <br /> Also get rid of all simple_strtoul() usage in conntrack, prefer a<br /> stricter version instead. There are intentional changes:<br /> <br /> - Bail out if number is &gt; UINT_MAX and indicate a failure, same for<br /> too long sequences.<br /> While we do accept 05535 as port 5535, we will not accept e.g.<br /> &amp;#39;sip:10.0.0.1:005060&amp;#39;. While its syntactically valid under RFC 3261,<br /> we should restrict this to not waste cycles when presented with<br /> malformed packets with 64k &amp;#39;0&amp;#39; characters.<br /> <br /> - Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch<br /> &amp;#39;expire=&amp;#39; and &amp;#39;rports=&amp;#39;; both are expected to use base-10.<br /> <br /> - In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k<br /> range.<br /> <br /> - epaddr_len now returns 0 if the port is invalid, as it already does<br /> for invalid ip addresses. This is intentional. nf_conntrack_sip<br /> performs lots of guesswork to find the right parts of the message<br /> to parse. Being stricter could break existing setups.<br /> Connection tracking helpers are designed to allow traffic to<br /> pass, not to block it.<br /> <br /> Based on an earlier patch from Jenny Guanni Qu .