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: <661ad1136bc10_3be9a7294c2@willemb.c.googlers.com.notmuch>
Date: Sat, 13 Apr 2024 14:38:11 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Richard Gobert <richardbgobert@...il.com>, 
 davem@...emloft.net, 
 edumazet@...gle.com, 
 kuba@...nel.org, 
 pabeni@...hat.com, 
 willemdebruijn.kernel@...il.com, 
 dsahern@...nel.org, 
 aleksander.lobakin@...el.com, 
 netdev@...r.kernel.org, 
 linux-kernel@...r.kernel.org, 
 alexander.duyck@...il.com
Cc: Richard Gobert <richardbgobert@...il.com>
Subject: Re: [PATCH net v1 1/2] net: gro: add flush check in
 udp_gro_receive_segment

Richard Gobert wrote:
> GRO-GSO path is supposed to be transparent and as such L3 flush checks are
> relevant to all flows which call skb_gro_receive. This patch uses the same
> logic and code from tcp_gro_receive but in the relevant flow path in
> udp_gro_receive_segment.
> 
> Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
> Signed-off-by: Richard Gobert <richardbgobert@...il.com>

Reviewed-by: Willem de Bruijn <willemb@...gle.com>

> ---
>  net/ipv4/udp_offload.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 3498dd1d0694..1f4e08f43c4b 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -471,6 +471,7 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
>  	struct sk_buff *p;
>  	unsigned int ulen;
>  	int ret = 0;
> +	int flush;
>  
>  	/* requires non zero csum, for symmetry with GSO */
>  	if (!uh->check) {
> @@ -528,7 +529,17 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
>  				skb_gro_postpull_rcsum(skb, uh,
>  						       sizeof(struct udphdr));
>  
> -				ret = skb_gro_receive(p, skb);
> +				flush = NAPI_GRO_CB(p)->flush;
> +
> +				if (NAPI_GRO_CB(p)->flush_id != 1 ||
> +				    NAPI_GRO_CB(p)->count != 1 ||
> +				    !NAPI_GRO_CB(p)->is_atomic)
> +					flush |= NAPI_GRO_CB(p)->flush_id;
> +				else
> +					NAPI_GRO_CB(p)->is_atomic = false;
> +
> +				if (flush || skb_gro_receive(p, skb))
> +					ret = 1;

UDP_L4 does not have the SKB_GSO_TCP_FIXEDID that uses is_atomic as
input.

And I still don't fully internalize the flush_id logic after staring
at it for more than one coffee.

But even ignoring those, the flush signal of NAPI_GRO_CB(p)->flush
set the network layer must be followed, so ACK. Thanks for the fix.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ