[PATCH net] tcp: limit tcp_tso_rtt_log to a valid shift count

[PATCH net] tcp: limit tcp_tso_rtt_log to a valid shift count

[Yingjie Wang]

tcp_tso_autosize() right-shifts the u32 returned by tcp_min_rtt() by
sysctl_tcp_tso_rtt_log. The sysctl uses proc_dou8vec_minmax() without
an upper bound, so it accepts values through 255. Values above 31 make
the shift undefined.

A process with CAP_NET_ADMIN in the target network namespace can set the
per-netns sysctl. With CONFIG_UBSAN_SHIFT=y, setting it to 32 and sending
TCP data over loopback triggers:

  UBSAN: shift-out-of-bounds in net/ipv4/tcp_output.c:2264:30
  shift exponent 32 is too large for 32-bit type 'unsigned int'
  Call Trace:
   __ubsan_handle_shift_out_of_bounds
   tcp_tso_segs
   tcp_write_xmit
   __tcp_push_pending_frames
   tcp_push
   tcp_sendmsg_locked

Limit the sysctl to 31, the largest valid shift count for a u32, and
document the accepted range. Writes of larger values now fail with
-EINVAL.

On a UBSAN/KASAN build of the net tree, values 0 and 31 remained
accepted, values 32 and 255 returned -EINVAL, and TCP traffic with the
valid boundary values produced no sanitizer diagnostics.

Fixes: 65466904b015 ("tcp: adjust TSO packet sizes based on min_rtt")
Cc: stable@vger.kernel.org
Signed-off-by: Yingjie Wang <1075151112@qq.com>
---
 Documentation/networking/ip-sysctl.rst | 2 ++
 net/ipv4/sysctl_net_ipv4.c             | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
index 8edd2eb2a..66a54c510 100644
--- a/Documentation/networking/ip-sysctl.rst
+++ b/Documentation/networking/ip-sysctl.rst
@@ -1128,6 +1128,8 @@ tcp_tso_rtt_log - INTEGER
 
 	If you want to use the old autosizing, set this sysctl to 0.
 
+	Possible values are [0, 31], inclusive.
+
 	Default: 9  (2^9 = 512 usec)
 
 tcp_pacing_ss_ratio - INTEGER
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index e3760daa3..e95431140 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -26,6 +26,7 @@ static int ip_local_port_range_max[] = { 65535, 65535 };
 static int tcp_adv_win_scale_min = -31;
 static int tcp_adv_win_scale_max = 31;
 static int tcp_app_win_max = 31;
+static int tcp_tso_rtt_log_max = 31;
 static int tcp_min_snd_mss_min = TCP_MIN_SND_MSS;
 static int tcp_min_snd_mss_max = 65535;
 static int tcp_rto_max_max = TCP_RTO_MAX_SEC * MSEC_PER_SEC;
@@ -778,6 +779,7 @@ static const struct ctl_table ipv4_net_table[] = {
 		.maxlen		= sizeof(u8),
 		.mode		= 0644,
 		.proc_handler	= proc_dou8vec_minmax,
+		.extra2		= &tcp_tso_rtt_log_max,
 	},
 	{
 		.procname	= "ip_early_demux",

base-commit: f4377bf85887f57b59abb5479f7660a81ffe4449
-- 
2.43.0

Re: [PATCH net] tcp: limit tcp_tso_rtt_log to a valid shift count

[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 net] tcp: limit tcp_tso_rtt_log to a valid shift count

[Eric Dumazet]

Le jeu. 22 oct. 2026 à 14:28, Yingjie Wang <1075151112@qq.com> a écrit :
>
> tcp_tso_autosize() right-shifts the u32 returned by tcp_min_rtt() by
> sysctl_tcp_tso_rtt_log. The sysctl uses proc_dou8vec_minmax() without
> an upper bound, so it accepts values through 255. Values above 31 make
> the shift undefined.
>
> A process with CAP_NET_ADMIN in the target network namespace can set the
> per-netns sysctl. With CONFIG_UBSAN_SHIFT=y, setting it to 32 and sending
> TCP data over loopback triggers:
>
>   UBSAN: shift-out-of-bounds in net/ipv4/tcp_output.c:2264:30
>   shift exponent 32 is too large for 32-bit type 'unsigned int'
>   Call Trace:
>    __ubsan_handle_shift_out_of_bounds
>    tcp_tso_segs
>    tcp_write_xmit
>    __tcp_push_pending_frames
>    tcp_push
>    tcp_sendmsg_locked
>
> Limit the sysctl to 31, the largest valid shift count for a u32, and
> document the accepted range. Writes of larger values now fail with
> -EINVAL.
>
> On a UBSAN/KASAN build of the net tree, values 0 and 31 remained
> accepted, values 32 and 255 returned -EINVAL, and TCP traffic with the
> valid boundary values produced no sanitizer diagnostics.
>
> Fixes: 65466904b015 ("tcp: adjust TSO packet sizes based on min_rtt")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yingjie Wang <1075151112@qq.com>

Reviewed-by: Eric Dumazet <edumazet@kernel.org>

Re: [PATCH net] tcp: limit tcp_tso_rtt_log to a valid shift count

[netdev-bot+sashiko]

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

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

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] The patch puts the new bound on the wrong sysctl, so it does not
  fix the bug it claims to fix.

--

tcp: limit tcp_tso_rtt_log to a valid shift count

This patch tries to cap the net.ipv4.tcp_tso_rtt_log sysctl at 31. The
reason is that tcp_tso_autosize() right-shifts a u32 by that value. The
patch also documents the accepted range [0, 31] in ip-sysctl.rst.

> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index e3760daa34706..e954311405b41 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c

[ ... ]

> @@ -778,6 +779,7 @@ static const struct ctl_table ipv4_net_table[] = {
>  		.maxlen		= sizeof(u8),
>  		.mode		= 0644,
>  		.proc_handler	= proc_dou8vec_minmax,
> +		.extra2		= &tcp_tso_rtt_log_max,
>  	},
>  	{
>  		.procname	= "ip_early_demux",

[Severity: High]
Was this hunk applied to the wrong ctl_table entry?

The entry just before "ip_early_demux" is "ip_dynaddr". With this patch
applied, ipv4_net_table reads:

	{
		.procname	= "ip_dynaddr",
		.data		= &init_net.ipv4.sysctl_ip_dynaddr,
		.maxlen		= sizeof(u8),
		.mode		= 0644,
		.proc_handler	= proc_dou8vec_minmax,
		.extra2		= &tcp_tso_rtt_log_max,
	},

The "tcp_tso_rtt_log" entry further down is unchanged and still has no
extra2:

	{
		.procname	= "tcp_tso_rtt_log",
		.data		= &init_net.ipv4.sysctl_tcp_tso_rtt_log,
		.maxlen		= sizeof(u8),
		.mode		= 0644,
		.proc_handler	= proc_dou8vec_minmax,
	},

When extra2 is NULL, proc_dou8vec_minmax() falls back to its default
maximum:

	unsigned int min = 0, max = 255U, val;
	...
	if (!tmp.extra2)
		tmp.extra2 = (unsigned int *) &max;

So writes of 32..255 to net.ipv4.tcp_tso_rtt_log are still accepted, and
tcp_tso_autosize() still does:

	r = tcp_min_rtt(tcp_sk(sk)) >> READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_tso_rtt_log);

Is the UBSAN shift-out-of-bounds from the commit message still reachable
through tcp_sendmsg_locked()->tcp_push()->tcp_write_xmit()->tcp_tso_segs()
->tcp_tso_autosize()? The r < BITS_PER_TYPE(sk->sk_gso_max_size) check
after it guards a different shift.

This also means the kernel does not enforce the new "Possible values are
[0, 31], inclusive." line in ip-sysctl.rst. This statement in the commit
message doesn't seem to match the diff:

    values 32 and 255 returned -EINVAL

Separately, net.ipv4.ip_dynaddr now rejects writes of 32..255 with
-EINVAL. Before this patch it accepted any u8 value.
inet_sk_rebuild_header() checks !sysctl_ip_dynaddr, and
inet_sk_reselect_saddr() checks sysctl_ip_dynaddr > 1, so both accept
larger values. With the Cc: stable tag, this change in what the sysctl
accepts would also reach stable kernels.

Should the extra2 line go in the tcp_tso_rtt_log entry instead?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/tencent_53CDCF8AA0022B75CF72A294CB9993D2FF07%40qq.com