linux-kernel - Re: [PATCH v3] net: fix wrong network header length

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: <41a3e6e4f9331c6a0a62fe838fc6f9084a5c89bc.camel@redhat.com>
Date:   Thu, 17 Feb 2022 09:45:27 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     Lina Wang <lina.wang@...iatek.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>
Cc:     Network Development <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        bpf <bpf@...r.kernel.org>,
        Maciej Żenczykowski <maze@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH v3] net: fix wrong network header length

Hello,

On Thu, 2022-02-17 at 15:01 +0800, Lina Wang wrote:
> On Wed, 2022-02-16 at 19:05 -0800, Alexei Starovoitov wrote:
> > On Tue, Feb 15, 2022 at 11:37 PM Lina Wang <lina.wang@...iatek.com>
> > wrote:
> > > 
> > > When clatd starts with ebpf offloaing, and NETIF_F_GRO_FRAGLIST is
> > > enable,
> > > several skbs are gathered in skb_shinfo(skb)->frag_list. The first
> > > skb's
> > > ipv6 header will be changed to ipv4 after bpf_skb_proto_6_to_4,
> > > network_header\transport_header\mac_header have been updated as
> > > ipv4 acts,
> > > but other skbs in frag_list didnot update anything, just ipv6
> > > packets.
> > 
> > Please add a test that demonstrates the issue and verifies the fix.
> 
> I used iperf udp test to verify the patch, server peer enabled -d to debug
> received packets.
> 
> 192.0.0.4 is clatd interface ip, corresponding ipv6 addr is 
> 2000:1:1:1:afca:1b1f:1a9:b367, server peer ip is 1.1.1.1,
> whose ipv6 is 2004:1:1:1::101:101.
> 
> Without the patch, when udp length 2840 packets received, iperf shows:
> pcount 1 packet_count 0
> pcount 27898727 packet_count 1
> pcount 3 packet_count 27898727
> 
> pcount should be 2, but is 27898727(0x1a9b367) , which is 20 bytes put 
> forward. 
> 
> 12:08:02.680299	Unicast to us 2004:1:1:1::101:101   2000:1:1:1:afca:1b1f:1a9:b367 UDP 51196 → 5201 Len=2840
> 0000   20 00 00 01 00 01 00 01 af ca 1b 1f 01 a9 b3 67   ipv6 dst address
> 0000   c7 fc 14 51 0b 20 c7 ab                           udp header
> 0000   00 00 00 ab 00 0e f3 49 00 00 00 01 08 06 69 d2   00000001 is pcount
> 12:08:02.682084	Unicast to us	1.1.1.1	                 192.0.0.4 	 	  UDP 51196 → 5201 Len=2840
> 
> After applied the patch, there is no OOO, pcount acted in order.

To clarify: Alexei is asking to add a test under:

tools/testing/selftests/net/

to cover this specific case. You can propbably extend the existing
udpgro_fwd.sh.

Please explicitly CC people who gave feedback to previous iterations,
it makes easier to track the discussion.

/P