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: <20211116173352.1a5ff66a@elisabeth>
Date:   Tue, 16 Nov 2021 17:33:52 +0100
From:   Stefano Brivio <sbrivio@...hat.com>
To:     Nikita Yushchenko <nikita.yushchenko@...tuozzo.com>
Cc:     Netdev <netdev@...r.kernel.org>, netfilter-devel@...r.kernel.org
Subject: Re: "AVX2-based lookup implementation" has broken ebtables
 --among-src

[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.

If you need a quick workaround, by the way, defining a "ether . ip"
set without the 'interval' flag and using a reference to it from the
nft rule will cause a switch to the nft_hash back-end (which presumably
doesn't have the same issue), see also:

	https://wiki.nftables.org/wiki-nftables/index.php/Portal:DeveloperDocs/set_internals

-- 
Stefano