From: Fernando Fernandez Mancera <fmancera@suse.de>
To: Duc Anh Luu <luuducanh05051995@gmail.com>,
pablo@netfilter.org, fw@strlen.de
Cc: netfilter-devel@vger.kernel.org, phil@nwl.cc,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] netfilter: nf_conntrack_sip: fix out-of-bounds read in ct_sip_parse_transport()
Date: Mon, 26 Oct 2026 15:08:46 +0100 [thread overview]
Message-ID: <3141c47e-6fa1-4012-a756-db565f7d1c03@suse.de> (raw)
In-Reply-To: <20261022172248.554687-1-luuducanh05051995@gmail.com>
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@gmail.com>
Hi, this is a dup of:
https://lore.kernel.org/netfilter-devel/179286139765.93379.986858959213810476@gmail.com/
Since the v1 was sent earlier, let's stick to that patch.
prev parent reply other threads:[~2026-10-26 14:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 17:22 Duc Anh Luu
2026-10-22 17:27 ` netdev-bot+sinfo
2026-10-26 14:08 ` Fernando Fernandez Mancera [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3141c47e-6fa1-4012-a756-db565f7d1c03@suse.de \
--to=fmancera@suse.de \
--cc=coreteam@netfilter.org \
--cc=fw@strlen.de \
--cc=linux-kernel@vger.kernel.org \
--cc=luuducanh05051995@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®