From: Dragos Tatulea <dtatulea@nvidia.com>
To: Tianyu Zuo <cosmosocket@gmail.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>, Mark Bloch <mbloch@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Khalid Manaa <khalidm@nvidia.com>,
Ben Ben-Ishay <benishay@nvidia.com>
Cc: Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net/mlx5e: SHAMPO, Fix IP length overflow on large HW GRO sessions
Date: Tue, 18 Aug 2026 11:44:12 +0200 [thread overview]
Message-ID: <6dab0f98-70b8-4c29-8993-bc06fefba2fa@nvidia.com> (raw)
In-Reply-To: <20260817181618.2786456-1-cosmosocket@gmail.com>
On 17.08.26 20:16, Tianyu Zuo wrote:
> mlx5e_hw_gro_skb_has_enough_space() bounds a HW GRO session by the
> payload held in the skb fragments only. The L3/L4 headers that
> header-data split placed in the linear area are not accounted for, and
> the limit is inclusive of GRO_LEGACY_MAX_SIZE.
>
> On a 4K page system a session can therefore grow to 16 full page
> fragments (65536 bytes) plus the 40 bytes of IPv4/TCP headers in the
> linear part, giving skb->len = 65576.
>
> mlx5e_shampo_update_hdr() writes the IP length itself:
>
> __be16 newlen = htons(skb->len - nhoff);
> csum_replace2(&ipv4->check, ipv4->tot_len, newlen);
> ipv4->tot_len = newlen;
>
> The result wraps. ip_rcv_core() then trims the 64KB skb down to the
> wrapped tot_len, silently dropping the payload. The IPv6 path wraps
> identically in ipv6hdr->payload_len.
>
> Both branches of the check are inclusive of GRO_LEGACY_MAX_SIZE, so a
> session can reach skb->len == 65536 and wrap tot_len to zero. In the
> page_size >= GRO_LEGACY_MAX_SIZE branch skb->len already covers the
> linear area, so that off by one is the only problem there. The fragment
> based branch additionally omits the linear area entirely.
>
> Account for skb_headlen() in the fragment based branch and make both
> comparisons strictly less than GRO_LEGACY_MAX_SIZE, so that skb->len can
> never exceed 65535. The new bound is strictly tighter than the old one,
> so the implicit limit on the fragment count (at most 65536 / page_size,
> well below MAX_SKB_FRAGS) is preserved.
>
> Fixes: 92552d3abd32 ("net/mlx5e: HW_GRO cqe handler implementation")
> Signed-off-by: Tianyu Zuo <cosmosocket@gmail.com>
> ---
> v2: commit message only, per review from Dragos and Tariq.
>
> v1: https://lore.kernel.org/netdev/20260729204745.166584-1-cosmosocket@gmail.com/
>
> drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> index 6fbc0441c4b8..2e9676305439 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> @@ -2222,9 +2222,10 @@ static bool mlx5e_hw_gro_skb_has_enough_space(struct sk_buff *skb,
> int nr_frags = skb_shinfo(skb)->nr_frags;
>
> if (page_size >= GRO_LEGACY_MAX_SIZE)
> - return skb->len + data_bcnt <= GRO_LEGACY_MAX_SIZE;
> + return skb->len + data_bcnt < GRO_LEGACY_MAX_SIZE;
> else
> - return page_size * nr_frags + data_bcnt <= GRO_LEGACY_MAX_SIZE;
> + return skb_headlen(skb) + page_size * nr_frags + data_bcnt <
> + GRO_LEGACY_MAX_SIZE;
> }
>
> static void mlx5e_handle_rx_cqe_mpwrq_shampo(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe)
>
> base-commit: 51b093a7ba27476e1f639455f005e8d2e75390e4
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Thanks,
Dragos
next prev parent reply other threads:[~2026-08-18 9:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 18:16 [PATCH net v2] net/mlx5e: SHAMPO, Fix IP length overflow on large HW GRO sessions Tianyu Zuo
2026-08-18 9:44 ` Dragos Tatulea [this message]
2026-08-19 23:03 ` Jakub Kicinski
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=6dab0f98-70b8-4c29-8993-bc06fefba2fa@nvidia.com \
--to=dtatulea@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=benishay@nvidia.com \
--cc=cosmosocket@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=khalidm@nvidia.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
/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.