linux-kernel - Re: [PATCH] maple_tree: not necessary to filter MAPLE_PARENT

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: <20221115145613.6wheb3gnsvparvki@revolver>
Date:   Tue, 15 Nov 2022 14:56:20 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Wei Yang <richard.weiyang@...il.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] maple_tree: not necessary to filter MAPLE_PARENT_ROOT
 since it is not a root

* Liam R. Howlett <Liam.Howlett@...cle.com> [221115 09:29]:
> * Wei Yang <richard.weiyang@...il.com> [221112 19:56]:
> > Root node is return at the beginning, so we are sure bit 0 is not set.
> > 
> > Signed-off-by: Wei Yang <richard.weiyang@...il.com>
> > CC: Liam R. Howlett <Liam.Howlett@...cle.com>
> > ---
> >  lib/maple_tree.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> > index 9aad98c24f3e..f8c4755e7c75 100644
> > --- a/lib/maple_tree.c
> > +++ b/lib/maple_tree.c
> > @@ -436,7 +436,7 @@ enum maple_type mte_parent_enum(struct maple_enode *p_enode,
> >  		return 0; /* Validated in the caller. */
> >  
> >  	p_type &= MAPLE_NODE_MASK;
> > -	p_type = p_type & ~(MAPLE_PARENT_ROOT | mte_parent_slot_mask(p_type));
> > +	p_type = p_type & ~mte_parent_slot_mask(p_type);
> 
> I think there is a larger cleanup that can be done here.  It looks like
> mte_parent_enum() is called from one location and that location is a
> wrapper.
> 
> The check for the root bit should also probably trigger a WARN_ON() and
> still return 0.  I don't think the callers are doing enough to validate
> it - although they should never reach this function with a root node.
> And, in fact, I am not doing enough in the test code since I didn't
> guard this correctly in the verification of the parent slot before
> calling this function.
> 
> Thanks for pointing this out.  I will send out a patch to clean this up
> shortly.

On second thought, I will hold off for the 6.2 merge window for this to
go upstream.

Thanks,
Liam