netdev - Re: [PATCH] netfilter: nft_paylaod: add base type NFT_PAYLOAD_LL_HEADER_NO

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: <20190618104548.xt5mee2iinx4ve6u@breakpoint.cc>
Date:   Tue, 18 Jun 2019 12:45:48 +0200
From:   Florian Westphal <fw@...len.de>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     Florian Westphal <fw@...len.de>, wenxu@...oud.cn,
        netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] netfilter: nft_paylaod: add base type
 NFT_PAYLOAD_LL_HEADER_NO_TAG

Pablo Neira Ayuso <pablo@...filter.org> wrote:
> On Tue, Jun 18, 2019 at 11:46:13AM +0200, Florian Westphal wrote:
> > Pablo Neira Ayuso <pablo@...filter.org> wrote:
> [...]
> > > Could you describe this problem a bit more? Small example rule plus
> > > scenario.
> > 
> > It was what wenxu reported originally:
> > 
> > nft add rule bridge filter forward ip protocol counter ..
> > 
> > The rule only matches if the ip packet is contained in an ethernet frame
> > without vlan tag -- and thats neither expected nor desirable.
> > 
> > This rule works when using 'meta protocol ip' as dependency instead
> > of ether type ip (what we do now), because VLAN stripping will fix/alter
> > skb->protocol to the inner type when the VLAN tag gets removes.
> > 
> > It will still fail in case there are several VLAN tags, so we might
> > need another meta expression that can figure out the l3 protocol type.
> 
> How would that new meta expression would look like?

I thought about extending nft_exthdr.c for L2, i.e. take
ether->type, and then advance to next vlan header (if vlan type)
until it either reaches skb network offset or an unknown type
(which would then be considered the last/topmost one and the one
 carrying the l3 protocol number).