[PATCH nf] netfilter: nf_conntrack_sip: only honour Via: port in original direction

[PATCH nf] netfilter: nf_conntrack_sip: only honour Via: port in original direction

[Joas Antonio dos Santos]

The Cisco phone workaround in process_sip_request() records the port
from the topmost Via: header in ct_sip_info->forced_dport whenever the
Via address matches the sender of the current request and the port
differs from the sender's source port.  nf_nat_sip() then rewrites the
UDP destination port of every reply-direction packet to that value.

The check is performed for requests in both directions.  For a request
arriving in the reply direction, ct->tuplehash[dir].tuple.src is the
remote peer's own address and port, so the remote side can trivially
satisfy the condition with a Via: line of the form

  Via: SIP/2.0/UDP <own-address>:<any-port>

and force forced_dport to a port of its choosing.  From then on,
packets it sends on this flow are delivered to the NATed host at that
port instead of the port the NAT mapping was created for, which bypasses
the port restriction normally enforced by the NAT mapping.

The workaround is only meant for phones behind the NAT router, i.e.
requests in the original direction.  Restrict it accordingly.

Fixes: 7266507d8999 ("netfilter: nf_ct_sip: support Cisco 7941/7945 IP phones")
Signed-off-by: Joas Antonio dos Santos <joasantonio108@gmail.com>
Assisted-by: Claude:claude-opus-5-5
---
Tested on 602042bf29f6 (arm64, QEMU) with client -> router -> server
network namespaces; the router runs nft masquerade and a "sip" ct helper
on udp/5060.  The client sends an OPTIONS request from port 5060; the
server answers with a request carrying "Via: SIP/2.0/UDP <server>:4444"
and then a plain UDP payload on the same flow.

  before: client receives both datagrams on port 4444
  after:  client receives both datagrams on port 5060

 net/netfilter/nf_conntrack_sip.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c
index 64bc440b1..ef655a0bb 100644
--- a/net/netfilter/nf_conntrack_sip.c
+++ b/net/netfilter/nf_conntrack_sip.c
@@ -1586,8 +1586,14 @@ static int process_sip_request(struct sk_buff *skb, unsigned int protoff,
 	 * router for one of these phones, save the port number from the
 	 * Via: header so that nf_nat_sip can redirect the responses to
 	 * the correct port.
+	 *
+	 * Only honour the Via: port for requests coming from the phone,
+	 * i.e. in the original direction.  The remote peer must not be
+	 * able to pick the destination port of packets delivered to the
+	 * NATed host.
 	 */
-	if (ct_sip_parse_header_uri(ct, *dptr, NULL, *datalen,
+	if (dir == IP_CT_DIR_ORIGINAL &&
+	    ct_sip_parse_header_uri(ct, *dptr, NULL, *datalen,
 				    SIP_HDR_VIA_UDP, NULL, &matchoff,
 				    &matchlen, &addr, &port) > 0 &&
 	    port != ct->tuplehash[dir].tuple.src.u.udp.port &&

Re: [PATCH nf] netfilter: nf_conntrack_sip: only honour Via: port in original direction

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH nf] netfilter: nf_conntrack_sip: only honour Via: port in original direction

[Joas Antonio]

Hi,

How the issue was discovered: manual code inspection of
nf_conntrack_sip.c / nf_nat_sip.c, assisted by an LLM (hence the
Assisted-by: tag), while auditing the conntrack helpers for
direction-handling issues.

I then confirmed it at runtime on 602042bf29f6 (QEMU, arm64) with
client -> router -> server network namespaces, the router running
nft masquerade and a "sip" ct helper on udp/5060. When the server
sends a request with "Via: SIP/2.0/UDP <server-ip>:4444", the client
behind the NAT receives that request and a following plain UDP payload
on port 4444; with the patch applied both arrive on 5060.

Thanks,
Joas


Em qua., 7 de out. de 2026 às 12:30, <netdev-bot+sinfo@kernel.org> escreveu:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.



-- 
Joas Antonio dos Santos
Cyber Security Specialist and Ethical Hacker
joasantonio108@gmail.com
LinkedIn

Re: [PATCH nf] netfilter: nf_conntrack_sip: only honour Via: port in original direction

[Pablo Neira Ayuso]

On Wed, Oct 07, 2026 at 12:52:19PM -0300, Joas Antonio wrote:
> Hi,
> 
> How the issue was discovered: manual code inspection of
> nf_conntrack_sip.c / nf_nat_sip.c, assisted by an LLM (hence the
> Assisted-by: tag), while auditing the conntrack helpers for
> direction-handling issues.
> 
> I then confirmed it at runtime on 602042bf29f6 (QEMU, arm64) with
> client -> router -> server network namespaces, the router running
> nft masquerade and a "sip" ct helper on udp/5060. When the server
> sends a request with "Via: SIP/2.0/UDP <server-ip>:4444", the client
> behind the NAT receives that request and a following plain UDP payload
> on port 4444; with the patch applied both arrive on 5060.

Sorry, this cannot be nf material.

It looks fairly theoretical to me, maybe for correctness patch? Is
this assuming a rogue server and packet spoofing?

> Thanks,
> Joas
> 
> 
> Em qua., 7 de out. de 2026 às 12:30, <netdev-bot+sinfo@kernel.org> escreveu:
> >
> > Hi!
> >
> > This is an automated message. This series looks like a fix, but its
> > commit messages seem to be missing some information:
> >
> >  - How the issue was discovered, e.g. hit in production, hit during
> >    development, syzbot report, manual code inspection, LLM or static
> >    analysis tool scan.
> >
> > Please do not repost the series just to address the above. Instead,
> > reply to this email with the missing information, so that reviewers
> > can take it into account. If the series needs another revision for
> > other reasons, please include the information in the commit messages
> > then.
> >
> > The evaluation is done by an LLM so it may be wrong, if you think
> > that is the case please reply and explain.
> 
> 
> 
> -- 
> Joas Antonio dos Santos
> Cyber Security Specialist and Ethical Hacker
> joasantonio108@gmail.com
> LinkedIn

Re: [PATCH nf] netfilter: nf_conntrack_sip: only honour Via: port in original direction

[Joas Antonio]

On Wed, Oct 07, 2026, Pablo Neira Ayuso wrote:
> Sorry, this cannot be nf material.
> It looks fairly theoretical to me, maybe for correctness patch? Is
> this assuming a rogue server and packet spoofing?

It assumes a rogue (or compromised) SIP peer, but no spoofing: the
peer only uses its own address in the Via: header, so any SIP server
or proxy the client talks to can do it. The effect is limited to that
peer's own flow: it can pick which port >= 1024 its datagrams are
delivered to on the NATed host, instead of the mapped port.

So I agree it is not urgent. I will resend it for nf-next as a
correctness fix, with how it was found in the commit message.

Thanks,
Joas


Em qua., 7 de out. de 2026 às 16:44, Pablo Neira Ayuso
<pablo@netfilter.org> escreveu:
>
> On Wed, Oct 07, 2026 at 12:52:19PM -0300, Joas Antonio wrote:
> > Hi,
> >
> > How the issue was discovered: manual code inspection of
> > nf_conntrack_sip.c / nf_nat_sip.c, assisted by an LLM (hence the
> > Assisted-by: tag), while auditing the conntrack helpers for
> > direction-handling issues.
> >
> > I then confirmed it at runtime on 602042bf29f6 (QEMU, arm64) with
> > client -> router -> server network namespaces, the router running
> > nft masquerade and a "sip" ct helper on udp/5060. When the server
> > sends a request with "Via: SIP/2.0/UDP <server-ip>:4444", the client
> > behind the NAT receives that request and a following plain UDP payload
> > on port 4444; with the patch applied both arrive on 5060.
>
> Sorry, this cannot be nf material.
>
> It looks fairly theoretical to me, maybe for correctness patch? Is
> this assuming a rogue server and packet spoofing?
>
> > Thanks,
> > Joas
> >
> >
> > Em qua., 7 de out. de 2026 às 12:30, <netdev-bot+sinfo@kernel.org> escreveu:
> > >
> > > Hi!
> > >
> > > This is an automated message. This series looks like a fix, but its
> > > commit messages seem to be missing some information:
> > >
> > >  - How the issue was discovered, e.g. hit in production, hit during
> > >    development, syzbot report, manual code inspection, LLM or static
> > >    analysis tool scan.
> > >
> > > Please do not repost the series just to address the above. Instead,
> > > reply to this email with the missing information, so that reviewers
> > > can take it into account. If the series needs another revision for
> > > other reasons, please include the information in the commit messages
> > > then.
> > >
> > > The evaluation is done by an LLM so it may be wrong, if you think
> > > that is the case please reply and explain.
> >
> >
> >
> > --
> > Joas Antonio dos Santos
> > Cyber Security Specialist and Ethical Hacker
> > joasantonio108@gmail.com
> > LinkedIn



-- 
Joas Antonio dos Santos
Cyber Security Specialist and Ethical Hacker
joasantonio108@gmail.com
LinkedIn