netdev - Re: "AVX2-based lookup implementation" has broken ebtables --among-src

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: <20211117120609.GI6326@breakpoint.cc>
Date:   Wed, 17 Nov 2021 13:06:09 +0100
From:   Florian Westphal <fw@...len.de>
To:     Stefano Brivio <sbrivio@...hat.com>
Cc:     Nikita Yushchenko <nikita.yushchenko@...tuozzo.com>,
        Netdev <netdev@...r.kernel.org>, netfilter-devel@...r.kernel.org
Subject: Re: "AVX2-based lookup implementation" has broken ebtables
 --among-src

Stefano Brivio <sbrivio@...hat.com> wrote:
> [Adding netfilter-devel]
> 
> Hi Nikita,
> 
> On Tue, 16 Nov 2021 11:51:01 +0300
> Nikita Yushchenko <nikita.yushchenko@...tuozzo.com> wrote:
> 
> > Hello Stefano.
> > 
> > I've found that nftables rule added by
> > 
> > # ebtables -A INPUT --among-src 8:0:27:40:f7:9=192.168.56.10 -j log
> > 
> > does not match packets on kernel 5.14 and on current mainline.
> > Although it matched correctly on kernel 4.18
> > 
> > I've bisected this issue. It was introduced by your commit 7400b063969b ("nft_set_pipapo: Introduce 
> > AVX2-based lookup implementation") from 5.7 development cycle.
> > 
> > The nftables rule created by the above command uses concatenation:
> > 
> > # nft list chain bridge filter INPUT
> > table bridge filter {
> >          chain INPUT {
> >                  type filter hook input priority filter; policy accept;
> >                  ether saddr . ip saddr { 08:00:27:40:f7:09 . 192.168.56.10 } counter packets 0 bytes 0 
> > log level notice flags ether
> >          }
> > }
> > 
> > Looks like the AVX2-based lookup does not process this correctly.
> 
> Thanks for bisecting and reporting this! I'm looking into it now, I
> might be a bit slow as I'm currently traveling.

Might be a bug in ebtables.  This is what nft monitor shows:

add chain bridge filter INPUT { type filter hook input priority filter;
	policy accept; }
	add rule bridge filter INPUT ether saddr . ip saddr {
08:00:27:40:f7:09 .
	   192.168.56.10-0x1297286e2b2 [..]

I can have a look at ebtables-nft side.