From: Ido Schimmel <idosch@nvidia.com>
To: Ren Wei <enjou1224z@gmail.com>,
edumazet@google.com, ncardwell@google.com
Cc: netdev@vger.kernel.org, dsahern@kernel.org, davem@davemloft.net,
edumazet@google.com, pabeni@redhat.com, horms@kernel.org,
vega@nebusec.ai, edragain@163.com
Subject: Re: [PATCH net 1/1] ipv4: reject RTAX_ADVMSS values below TCP_MIN_MSS
Date: Thu, 30 Jul 2026 16:35:46 +0300 [thread overview]
Message-ID: <20260730133546.GA1761428@shredder> (raw)
In-Reply-To: <a2e93ae9003f33bf49b789dbd537f4a6c10f26fa.1784972917.git.edragain@163.com>
On Tue, Jul 28, 2026 at 01:08:17PM +0800, Ren Wei wrote:
> From: Yong Wang <edragain@163.com>
>
> ip_metrics_convert() only caps RTAX_ADVMSS at the upper bound and
> still accepts undersized non-zero values from userspace.
>
> A route installed with "advmss 12" can later reach the passive TCP
> open path. When SYN timestamps are enabled, tcp_openreq_init_rwin()
> subtracts TCPOLEN_TSTAMP_ALIGNED from the route advmss before calling
> tcp_select_initial_window(). This can reduce the effective MSS to
> zero and trigger a divide-by-zero in the rounddown(space, mss) path.
>
> Reject non-zero RTAX_ADVMSS values smaller than TCP_MIN_MSS while
> keeping the existing "0 means use default advmss" behavior intact.
>
> This matches the existing TCP_MIN_MSS based validation used for
> TCP_MAXSEG and fixes the bug at the route metric input point rather
> than adding a redundant guard deeper in the TCP stack.
Eric / Neal, the comment above tcp_select_initial_window() says:
"[...]. We assume here that mss >= 1. This MUST be enforced by all
callers".
AFAICT, tcp_openreq_init_rwin() and tcp_connect_init() are the only
callers that subtract the size of the timestamp option from the MSS
without validating the result.
Fixing it there also takes care of the comment from Sashiko regarding
RTAX_MTU:
"If an unprivileged user sets the namespace specific sysctl
net.ipv4.route.min_adv_mss to 0 (which is accessible due to an exporting
flaw) and adds a route with an MTU of 52, the IPv4 stack evaluates the
default advmss as max(MTU - 40, min_adv_mss), yielding 12.
[...]
Should a similar lower bound check be enforced for RTAX_MTU during
netlink conversion to prevent this bypass?"
Do you prefer to fix this in TCP?
Sashiko link:
https://sashiko.dev/#/patchset/a2e93ae9003f33bf49b789dbd537f4a6c10f26fa.1784972917.git.edragain%40163.com
Patch link:
https://lore.kernel.org/netdev/cover.1784972917.git.edragain@163.com/
Thanks
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Reported-by: Vega <vega@nebusec.ai>
> Assisted-by: Codex:GPT-5.4
> Signed-off-by: Yong Wang <edragain@163.com>
> Signed-off-by: Ren Wei <enjou1224z@gmail.com>
> ---
> net/ipv4/metrics.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/ipv4/metrics.c b/net/ipv4/metrics.c
> index ad40762a8b38..b9b97a0a5126 100644
> --- a/net/ipv4/metrics.c
> +++ b/net/ipv4/metrics.c
> @@ -44,6 +44,12 @@ static int ip_metrics_convert(struct nlattr *fc_mx,
> }
> val = nla_get_u32(nla);
> }
> + if (type == RTAX_ADVMSS && val && val < TCP_MIN_MSS) {
> + NL_SET_ERR_MSG_ATTR_FMT(extack, nla,
> + "Invalid advmss, must be 0 or >= %u",
> + TCP_MIN_MSS);
> + return -EINVAL;
> + }
> if (type == RTAX_ADVMSS && val > 65535 - 40)
> val = 65535 - 40;
> if (type == RTAX_MTU && val > 65535 - 15)
> --
> 2.53.0
prev parent reply other threads:[~2026-07-30 13:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 5:08 [PATCH net 0/1] ipv4: fix divide-by-zero from undersized RTAX_ADVMSS Ren Wei
2026-07-28 5:08 ` [PATCH net 1/1] ipv4: reject RTAX_ADVMSS values below TCP_MIN_MSS Ren Wei
2026-07-30 13:35 ` Ido Schimmel [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=20260730133546.GA1761428@shredder \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edragain@163.com \
--cc=edumazet@google.com \
--cc=enjou1224z@gmail.com \
--cc=horms@kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vega@nebusec.ai \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.