mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] netfilter: conntrack_irc: fix port value truncation in parse_dcc()
@ 2026-09-06 23:37 Aamir Ahmed
  2026-09-07  8:32 ` Florian Westphal
  2026-09-09 21:40 ` netdev-bot+sashiko
  0 siblings, 2 replies; 5+ messages in thread
From: Aamir Ahmed @ 2026-09-06 23:37 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: netfilter-devel, coreteam, netdev, linux-kernel, stable

parse_dcc() uses simple_strtoul() to parse the port number from DCC
commands, storing the result directly in a u16.  simple_strtoul()
returns unsigned long, so values above 65535 are silently truncated.
For example, a DCC command with port "65537" is parsed as port 1,
bypassing the dcc_port == 0 rejection check and creating a conntrack
expectation for an unintended port.

The nf_conntrack_ftp helper had the same class of defect and was fixed
by using a wider accumulator with a range check (get_port checks
tmp_port > 65535).  The ipvs ftp helper was similarly fixed in commit
e625a9477d12 ("ipvs: fix integer overflow in ftp helper port/address
parsing").  Apply the same pattern here: parse into an unsigned long,
reject values above 65535, and only then assign to the u16.

Fixes: 869f37d8e48f ("[NETFILTER]: nf_conntrack/nf_nat: add IRC helper port")
Signed-off-by: Aamir Ahmed <elb12345@hotmail.co.uk>
---
 net/netfilter/nf_conntrack_irc.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/netfilter/nf_conntrack_irc.c b/net/netfilter/nf_conntrack_irc.c
index 92360963757a..8321f12dbf15 100644
--- a/net/netfilter/nf_conntrack_irc.c
+++ b/net/netfilter/nf_conntrack_irc.c
@@ -64,6 +64,7 @@ static int parse_dcc(char *data, const char *data_end, __be32 *ip,
 		     u_int16_t *port, char **ad_beg_p, char **ad_end_p)
 {
 	char *tmp;
+	unsigned long tmp_port;
 
 	/* at least 12: "AAAAAAAA P\1\n" */
 	while (*data++ != ' ')
@@ -88,7 +89,10 @@ static int parse_dcc(char *data, const char *data_end, __be32 *ip,
 		data++;
 	}
 
-	*port = simple_strtoul(data, &data, 10);
+	tmp_port = simple_strtoul(data, &data, 10);
+	if (tmp_port > 65535)
+		return -1;
+	*port = tmp_port;
 	*ad_end_p = data;
 
 	return 0;
-- 
2.43.0


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] netfilter: conntrack_irc: fix port value truncation in parse_dcc()
  2026-09-06 23:37 [PATCH] netfilter: conntrack_irc: fix port value truncation in parse_dcc() Aamir Ahmed
@ 2026-09-07  8:32 ` Florian Westphal
  2026-09-08  2:03   ` Aamir Ahmed
  2026-09-09 21:40 ` netdev-bot+sashiko
  1 sibling, 1 reply; 5+ messages in thread
From: Florian Westphal @ 2026-09-07  8:32 UTC (permalink / raw)
  To: Aamir Ahmed
  Cc: Pablo Neira Ayuso, netfilter-devel, coreteam, netdev,
	linux-kernel, stable

Aamir Ahmed <elb12345@hotmail.co.uk> wrote:
> diff --git a/net/netfilter/nf_conntrack_irc.c b/net/netfilter/nf_conntrack_irc.c
> index 92360963757a..8321f12dbf15 100644
> --- a/net/netfilter/nf_conntrack_irc.c
> +++ b/net/netfilter/nf_conntrack_irc.c
> @@ -64,6 +64,7 @@ static int parse_dcc(char *data, const char *data_end, __be32 *ip,
>  		     u_int16_t *port, char **ad_beg_p, char **ad_end_p)
>  {
>  	char *tmp;
> +	unsigned long tmp_port;
>  
>  	/* at least 12: "AAAAAAAA P\1\n" */
>  	while (*data++ != ' ')
> @@ -88,7 +89,10 @@ static int parse_dcc(char *data, const char *data_end, __be32 *ip,
>  		data++;
>  	}
>  
> -	*port = simple_strtoul(data, &data, 10);
> +	tmp_port = simple_strtoul(data, &data, 10);
> +	if (tmp_port > 65535)
> +		return -1;

Your other patch also rejects port == 0.
Maybe also check and refuse for tmp_port < 1024 here.

This patch can be handled via nf-next, I think.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] netfilter: conntrack_irc: fix port value truncation in parse_dcc()
  2026-09-07  8:32 ` Florian Westphal
@ 2026-09-08  2:03   ` Aamir Ahmed
  0 siblings, 0 replies; 5+ messages in thread
From: Aamir Ahmed @ 2026-09-08  2:03 UTC (permalink / raw)
  To: Florian Westphal
  Cc: Aamir Ahmed, Pablo Neira Ayuso, netfilter-devel, coreteam,
	netdev, linux-kernel, stable

On Mon, Sep 07, 2026 at 10:32:17AM +0200, Florian Westphal wrote:
> Your other patch also rejects port == 0.
> Maybe also check and refuse for tmp_port < 1024 here.

Makes sense - the expectation is source-wildcarded and the DCC port is
the client's own listener, so a privileged port there is not something
the helper should open. v2 will reject tmp_port < 1024 || > 65535 and
drop the now-redundant dcc_port == 0 test in help() (or I can put the
floor there instead, so the forged-DCC warning still fires - your
preference). I will describe it as a behaviour change with your
Suggested-by rather than part of the truncation fix.

While respinning I noticed simple_strtoul() narrows to 32 bits before
the range check on 32-bit, so v2 will use simple_strtoull().

> This patch can be handled via nf-next, I think.

Will resend as [PATCH nf-next v2], without the stable Cc.

Kind Regards

Aamir A.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] netfilter: conntrack_irc: fix port value truncation in parse_dcc()
@ 2026-09-09 21:40 ` netdev-bot+sashiko
  2026-09-09 23:33   ` Aamir Ahmed
  0 siblings, 1 reply; 5+ messages in thread
From: netdev-bot+sashiko @ 2026-09-09 21:40 UTC (permalink / raw)
  To: elb12345
  Cc: pablo, netfilter-devel, coreteam, netdev, linux-kernel, stable, kuba

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 1 · Medium: 0 · Low: 0

- [High] Incomplete fix: in parse_dcc()
  (net/netfilter/nf_conntrack_irc.c:92-95) the new bound check is…

--

netfilter: conntrack_irc: fix port value truncation in parse_dcc()

This adds a bound check to the DCC port parsing in parse_dcc() so that
values above 65535 are rejected instead of being silently truncated into
the u16 output.  The stated goal is to prevent a conntrack expectation
being created for a port that never appeared in the DCC command.

> diff --git a/net/netfilter/nf_conntrack_irc.c b/net/netfilter/nf_conntrack_irc.c
> index 92360963757a9..8321f12dbf155 100644
> --- a/net/netfilter/nf_conntrack_irc.c
> +++ b/net/netfilter/nf_conntrack_irc.c
> @@ -64,6 +64,7 @@ static int parse_dcc(char *data, const char *data_end, __be32 *ip,
>  		     u_int16_t *port, char **ad_beg_p, char **ad_end_p)
>  {
>  	char *tmp;
> +	unsigned long tmp_port;

[Severity: High]
Is unsigned long wide enough here on 32-bit builds?

> @@ -88,7 +89,10 @@ static int parse_dcc(char *data, const char *data_end, __be32 *ip,
>  		data++;
>  	}
>  
> -	*port = simple_strtoul(data, &data, 10);
> +	tmp_port = simple_strtoul(data, &data, 10);
> +	if (tmp_port > 65535)
> +		return -1;
> +	*port = tmp_port;

Does the truncation still happen before the new check runs on ILP32
(i386, ARM32, MIPS32), where unsigned long is 32 bits?

simple_strtoul() itself narrows:

lib/vsprintf.c:
unsigned long simple_strtoul(const char *cp, char **endp, unsigned int base)
{
	return simple_strtoull(cp, endp, base);
}

And _parse_integer_limit() in lib/kstrtox.c only saturates to ULLONG_MAX
when check_mul_overflow()/check_add_overflow() fire, so a value in the
2^32 range is returned exactly as a 64-bit result:

		if (unlikely(res & (~0ull << 60))) {
			if (check_mul_overflow(res, base, &res) ||
			    check_add_overflow(res, val, &res)) {
				res = ULLONG_MAX;
				overflow = KSTRTOX_OVERFLOW;

So for a DCC field of "4294967297", would the 64-bit 0x1_00000001 be
narrowed to 1 by the assignment into tmp_port, making tmp_port > 65535
false and leaving *port == 1?

If so, the path in help() would still be reached with a port that was
never in the command, since the only remaining guard is dcc_port == 0:

net/netfilter/nf_conntrack_irc.c:help() {
	...
			    dcc_port == 0) {
	...
			port = htons(dcc_port);
			nf_ct_expect_init(exp, NF_CT_EXPECT_CLASS_DEFAULT,
					  tuple->src.l3num,
					  NULL, &tuple->dst.u3,
					  IPPROTO_TCP, NULL, &port);
	...
}

The input here is remote IRC payload copied into irc_buffer by help(),
and parse_dcc() only requires a '\n' inside the buffer, so a payload of
the form "PRIVMSG x :\1DCC SEND t <ip> 4294967297\1\n" reaches this
parse.

The commit message says this follows nf_conntrack_ftp:

  "The nf_conntrack_ftp helper had the same class of defect and was fixed
  by using a wider accumulator with a range check (get_port checks
  tmp_port > 65535).  Apply the same pattern here"

Is that equivalent, though?  get_port() uses a fixed-width u32 and
re-tests after every digit, so it cannot be affected by the width of
unsigned long:

net/netfilter/nf_conntrack_ftp.c:get_port() {
	u32 tmp_port = 0;
	...
		} else if (data[i] >= '0' && data[i] <= '9') {
			tmp_port = tmp_port*10 + data[i] - '0';
			if (tmp_port > 65535)
				break;
	...
}

Would a width-independent form work better here, for example parsing
with simple_strtoull() into an unsigned long long, using kstrtou16() and
checking for -ERANGE, or the ftp-style per-digit bound?

>  	*ad_end_p = data;
>  
>  	return 0;

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/AS8P251MB0001B81958B28F762352EF3DC8B32%40AS8P251MB0001.EURP251.PROD.OUTLOOK.COM

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] netfilter: conntrack_irc: fix port value truncation in parse_dcc()
  2026-09-09 21:40 ` netdev-bot+sashiko
@ 2026-09-09 23:33   ` Aamir Ahmed
  0 siblings, 0 replies; 5+ messages in thread
From: Aamir Ahmed @ 2026-09-09 23:33 UTC (permalink / raw)
  To: netdev-bot+sashiko
  Cc: Aamir Ahmed, Florian Westphal, Pablo Neira Ayuso,
	netfilter-devel, coreteam, netdev, linux-kernel, kuba, rc

On Wed, Sep 09, 2026 at 09:40:13PM +0000, Sashiko AI review wrote:
> Does the truncation still happen before the new check runs on ILP32
> (i386, ARM32, MIPS32), where unsigned long is 32 bits?

Yes, it does.

Florian mentioned on the amanda thread a queued series which adds a
shared parser for all the helpers:

  https://patchwork.ozlabs.org/project/netfilter-devel/patch/20260503083220.630655-2-rc@rexion.ai/

That should cover this. I will drop my patch for now, thanks.

Kind Regards

Aamir A.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-09-09 23:33 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-06 23:37 [PATCH] netfilter: conntrack_irc: fix port value truncation in parse_dcc() Aamir Ahmed
2026-09-07  8:32 ` Florian Westphal
2026-09-08  2:03   ` Aamir Ahmed
2026-09-09 21:40 ` netdev-bot+sashiko
2026-09-09 23:33   ` Aamir Ahmed

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®