Re: [PATCH] netfilter: nf_conntrack_sip: fix out-of-bounds read in ct_sip_parse_transport()

[Fernando Fernandez Mancera]

On 10/22/26 7:22 PM, Duc Anh Luu wrote:
> ct_sip_parse_transport() compares the "transport=" parameter value against
> "TCP" and "UDP" with a fixed length of 3, without first checking that the
> parsed value is that long:
>
> 	if (ct_sip_parse_param(ct, dptr, dataoff, datalen, "transport=",
> 			       &matchoff, &matchlen)) {
> 		if (!strncasecmp(dptr + matchoff, "TCP", strlen("TCP")))
> 		...
>
> ct_sip_parse_param() sets the value end to the surrounding limit when no
> ';' delimiter follows, and that limit can be the end of the SIP message
> (dptr + datalen) when no ',' is present either. A Contact/Via parameter
> such as "transport=tc" placed at the very end of the payload therefore
> yields matchlen < 3 with matchoff + matchlen == datalen, and the
> strncasecmp() reads up to two bytes past the end of the message buffer.
>
> The value of the over-read bytes can also flip the detected transport,
> so this is not purely a read: a crafted short value can make the helper
> classify the transport using out-of-bounds data.
>
> Both call sites (process_register_request() and
> process_register_response()) are reached from attacker-supplied SIP
> traffic when the nf_conntrack_sip helper is active.
>
> Bound each comparison by matchlen. A value shorter than three characters
> can never equal "TCP"/"UDP", so this only rejects already-malformed input
> and leaves valid transports (TCP, UDP, TLS, SCTP, ...) unchanged.
>
> Reachability and behavioural equivalence were verified with a userspace
> ASan harness built from the verbatim parser functions: the over-read is
> confirmed as a read past dptr + datalen, and the fix removes it while
> producing identical results for all well-formed transport values.
>
> Fixes: f5b321bd37fb ("netfilter: nf_conntrack_sip: add TCP support")
> Signed-off-by: Duc Anh Luu <luuducanh05051995@xxxxxxxxx>
Hi, this is a dup of:

https://lore.kernel.org/netfilter-devel/179286139765.93379.986858959213810476@xxxxxxxxx/

Since the v1 was sent earlier, let's stick to that patch.