linux-kernel - Re: lib/idr.c: initialize struct idr

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]

Date:	Sun, 27 Jan 2008 22:17:36 +0100
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Pekka Enberg" <penberg@...helsinki.fi>
Cc:	"Jim Houston" <jim.houston@...r.com>,
	"Ingo Molnar" <mingo@...e.hu>, "Tejun Heo" <htejun@...il.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: lib/idr.c: initialize struct idr_layer

On Jan 27, 2008 10:00 PM, Pekka Enberg <penberg@...helsinki.fi> wrote:
> Hi Vegard,
>
> On Jan 27, 2008 10:07 PM, Vegard Nossum <vegard.nossum@...il.com> wrote:
> > I am testing my kmemcheck patches, and it has come up with a couple of
> > uses of uninitialized memory in lib/idr.c. These are (the line numbers
> > may differ slightly):
>
> [snip]
>
> > @@ -39,12 +39,16 @@ static struct idr_layer *alloc_layer(struct idr *idp)
> >  {
> >         struct idr_layer *p;
> >         unsigned long flags;
> > +       int i;
> >
> >         spin_lock_irqsave(&idp->lock, flags);
> >         if ((p = idp->id_free)) {
> >                 idp->id_free = p->ary[0];
> >                 idp->id_free_cnt--;
> > -               p->ary[0] = NULL;
> > +               p->bitmap = 0;
> > +               for(i = 0; i < ARRAY_SIZE(p->ary); ++i)
> > +                       p->ary[i] = NULL;
> > +               p->count = 0;
>
> But aren't these zeroed by idr_cache_ctor() already?

That would make sense. However...

idr_layer_cache is only used for allocations from idr_pre_get().
idr_pre_get() is only called from ida_pre_get().

If this analysis is correct, can this mean that the user has failed to
call ida_pre_get() before idr_get_new() was called?

Though in this case, idr_pre_get() actually *is* called first. Hmm...
I think there's a pretty big chance that kmemcheck is at fault :-(

Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/