Re: [PATCH nf 0/2] nft_set_pipapo: Fix crash due to dangling entries in mapping table

[Stefano Brivio <sbrivio@redhat.com>]

On Wed, 26 Feb 2020 12:34:43 +0100
Pablo Neira Ayuso <pablo@netfilter.org> wrote:

> On Wed, Feb 26, 2020 at 12:19:24PM +0100, Stefano Brivio wrote:
> > On Wed, 26 Feb 2020 12:10:56 +0100
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> >   
> > > On Wed, Feb 26, 2020 at 11:59:24AM +0100, Stefano Brivio wrote:
> > > [...]  
> > > > One detail, unrelated to this patch, that I should probably document in
> > > > man pages and Wiki (I forgot, it occurred to me while testing): it is
> > > > allowed to insert an entry if a proper subset of it, with no
> > > > overlapping bounds, is already inserted. The reverse sequence is not
> > > > allowed. This can be used without ambiguity due to strict guarantees
> > > > about ordering. That is:
> > > > 
> > > > # nft add element t s '{ 1.0.0.20-1.0.0.21 . 3.3.3.3 }'
> > > > # nft add element t s '{ 1.0.0.10-1.0.0.100 . 3.3.3.3 }'    
> > > 
> > > OK, so first element "shadows" the second one. And the first element
> > > will matching in case that address is 1.0.0.20 and 10.0.0.21. Right?  
> > 
> > Correct.  
> 
> So this is happening because the result bitmap contains the pipapo
> rules that represent the first element and the second. But when
> iterating over the result bitmap bits, the pipapo rule that represents
> the first element is taken as the matching one, right?

Right.

> I mean, to catch elements that represents subsets/supersets of another
> element (like in this example above), pipapo would need to make a
> lookup for already matching rules for this new element?

Right, and that's what those two pipapo_get() calls in
nft_pipapo_insert() do.

-- 
Stefano