linux-kernel - RE: [RFC PATCH 1/1] idr: do not create idr if new id would be outside given range

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: <IA4PR11MB92511BAEF257742C82ED590199DCA@IA4PR11MB9251.namprd11.prod.outlook.com>
Date: Fri, 28 Nov 2025 16:47:17 +0000
From: "Sokolowski, Jan" <jan.sokolowski@...el.com>
To: Matthew Wilcox <willy@...radead.org>
CC: Christian König <christian.koenig@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Andrew Morton
	<akpm@...ux-foundation.org>, "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: RE: [RFC PATCH 1/1] idr: do not create idr if new id would be outside
 given range



> -----Original Message-----
> From: Matthew Wilcox <willy@...radead.org>
> Sent: Friday, November 28, 2025 4:52 PM
> To: Sokolowski, Jan <jan.sokolowski@...el.com>
> Cc: Christian König <christian.koenig@....com>; linux-
> kernel@...r.kernel.org; Andrew Morton <akpm@...ux-foundation.org>;
> linux-fsdevel@...r.kernel.org; linux-mm@...ck.org
> Subject: Re: [RFC PATCH 1/1] idr: do not create idr if new id would be outside
> given range
> 
> On Fri, Nov 28, 2025 at 09:03:08AM +0000, Sokolowski, Jan wrote:
> > So, shall I send a V2 of that patch and add you as co-developer there?
> 
> No.  You didn't co-develop anything.  You reported the bug, badly.
> 
And I've sent a potential patch on how it should've been fixed. That should count for something, right?


> What I'm trying to do right now is figure out what the syzbot report
> actually was.  In all the DRM specialness, you've lost the original
> information, so I can't add the original syzbot links.  All I can find
> is https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6449
> which doesn't link to a syzbot report, so that's a dead end.
> 
> > Regards
> > Jan
> >
> > > -----Original Message-----
> > > From: Matthew Wilcox <willy@...radead.org>
> > > Sent: Thursday, November 27, 2025 3:55 PM
> > > To: Christian König <christian.koenig@....com>
> > > Cc: Sokolowski, Jan <jan.sokolowski@...el.com>; linux-
> > > kernel@...r.kernel.org; Andrew Morton <akpm@...ux-foundation.org>;
> > > linux-fsdevel@...r.kernel.org; linux-mm@...ck.org
> > > Subject: Re: [RFC PATCH 1/1] idr: do not create idr if new id would be
> outside
> > > given range
> > >
> > > On Thu, Nov 27, 2025 at 02:11:02PM +0000, Matthew Wilcox wrote:
> > > > Hm.  That's not what it does for me.  It gives me id == 1, which isn't
> > > > correct!  I'll look into that, but it'd be helpful to know what
> > > > combination of inputs gives us 2.
> > >
> > > Oh, never mind, I see what's happening.
> > >
> > > int idr_alloc(struct idr *idr, void *ptr, int start, int end, gfp_t gfp)
> > >
> > >         ret = idr_alloc_u32(idr, ptr, &id, end > 0 ? end - 1 : INT_MAX, gfp);
> > > so it's passing 0 as 'max' to idr_alloc_u32() which does:
> > >
> > >         slot = idr_get_free(&idr->idr_rt, &iter, gfp, max - base);
> > >
> > > and max - base becomes -1 or rather ULONG_MAX, and so we'll literally
> > > allocate any number.  If the first slot is full, we'll get back 1
> > > and then add 'base' to it, giving 2.
> > >
> > > Here's the new test-case:
> > >
> > > +void idr_alloc2_test(void)
> > > +{
> > > +       int id;
> > > +       struct idr idr = IDR_INIT_BASE(idr, 1);
> > > +
> > > +       id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL);
> > > +       assert(id == -ENOSPC);
> > > +
> > > +       id = idr_alloc(&idr, idr_alloc2_test, 1, 2, GFP_KERNEL);
> > > +       assert(id == 1);
> > > +
> > > +       id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL);
> > > +       assert(id == -ENOSPC);
> > > +
> > > +       id = idr_alloc(&idr, idr_alloc2_test, 0, 2, GFP_KERNEL);
> > > +       assert(id == -ENOSPC);
> > > +
> > > +       idr_destroy(&idr);
> > > +}
> > >
> > > and with this patch, it passes:
> > >
> > > +++ b/lib/idr.c
> > > @@ -40,6 +40,8 @@ int idr_alloc_u32(struct idr *idr, void *ptr, u32
> *nextid,
> > >
> > >         if (WARN_ON_ONCE(!(idr->idr_rt.xa_flags & ROOT_IS_IDR)))
> > >                 idr->idr_rt.xa_flags |= IDR_RT_MARKER;
> > > +       if (max < base)
> > > +               return -ENOSPC;
> > >
> > >         id = (id < base) ? 0 : id - base;
> > >         radix_tree_iter_init(&iter, id);
> >