netdev - Re: [v5,net-next,08/10] geneve: extract hint option at GRO stage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260123175313.1286366-1-horms@kernel.org>
Date: Fri, 23 Jan 2026 17:53:13 +0000
From: Simon Horman <horms@...nel.org>
To: pabeni@...hat.com
Cc: Simon Horman <horms@...nel.org>,
	petrm@...dia.com,
	willemdebruijn.kernel@...il.com,
	shuah@...nel.org,
	sdf@...ichev.me,
	idosch@...dia.com,
	davem@...emloft.net,
	netdev@...r.kernel.org,
	andrew+netdev@...n.ch,
	edumazet@...gle.com,
	donald.hunter@...il.com,
	razor@...ckwall.org,
	kuba@...nel.org
Subject: Re: [v5,net-next,08/10] geneve: extract hint option at GRO stage

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
geneve: extract hint option at GRO stage

This patch adds helpers for finding and validating a GRO hint option in
the geneve header and uses them to extract hint info at the GRO stage.

> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index a4c23240d9e3..2e1f85b8af4e 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c

[ ... ]

> +static unsigned int
> +geneve_opt_gro_hint_off(const struct genevehdr *gh, __be16 *type,
> +			unsigned int *gh_len)
> +{

[ ... ]

> +	*type = proto_id_map[id];
> +	*gh_len += gro_hint->nested_hdr_len;
> +
> +	return (void *)gro_hint - (void *)gh;
> +}

[ ... ]

> @@ -541,13 +700,13 @@ static struct sk_buff *geneve_gro_receive(struct sock *sk,
>  					  struct list_head *head,
>  					  struct sk_buff *skb)
>  {
> +	unsigned int hlen, gh_len, off_gnv, hint_off;

[ ... ]

> +	/* The GRO hint/nested hdr could use a different ethernet type. */
> +	hint_off = geneve_sk_gro_hint_off(sk, gh, &type, &gh_len);

When geneve_sk_gro_hint_off() succeeds (hint_off != 0), gh_len is increased
by nested_hdr_len. The current packet is then validated for this larger
size via skb_gro_header().

> +	if (hint_off) {
> +		const struct geneve_opt_gro_hint *gro_hint;
> +
> +		/*
> +		 * If the hint is present, and nested hdr validation fails, do
> +		 * not attempt plain GRO: it will ignore inner hdrs and cause
> +		 * OoO.
> +		 */
> +		gh = skb_gro_header(skb, off_gnv + gh_len, off_gnv);
> +		if (unlikely(!gh))
> +			goto out;
> +
> +		gro_hint = geneve_opt_gro_hint(gh, hint_off);
> +		if (!geneve_opt_gro_hint_validate_csum(skb, gh, gro_hint))
> +			goto out;
> +	}
> +
>  	list_for_each_entry(p, head, list) {
>  		if (!NAPI_GRO_CB(p)->same_flow)
>  			continue;
>
>  		gh2 = (struct genevehdr *)(p->data + off_gnv);
>  		if (gh->opt_len != gh2->opt_len ||
>  		    memcmp(gh, gh2, gh_len)) {
                            ^^^^^^

When the current packet has a hint option and gh_len has been increased to
include nested_hdr_len, the memcmp reads gh_len bytes from gh2. However,
packet p in the GRO list may have been processed without a hint option
(even on the same socket, if the packet itself lacks the geneve hint
option), meaning it was only validated for geneve_hlen() bytes.

Could memcmp read beyond the validated region of packet p? The socket can
have gro_hint enabled while individual packets may or may not contain the
hint option. If p lacks the option, it was validated for a smaller size
than gh_len.

Note: this appears to be addressed in the next patch in the series
(566c51bcb23e "geneve: use GRO hint option in the RX path") which
introduces geneve_hdr_match() that recalculates gh_len = geneve_hlen(gh)
before the memcmp and handles nested header comparison separately.

> @@ -580,7 +759,6 @@ static struct sk_buff *geneve_gro_receive(struct sock *sk,
>
>  	skb_gro_pull(skb, gh_len);
>  	skb_gro_postpull_rcsum(skb, gh, gh_len);