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: <IA4PR11MB9251BBCF39B18A557BF08C0799DCA@IA4PR11MB9251.namprd11.prod.outlook.com>
Date: Fri, 28 Nov 2025 09:03:08 +0000
From: "Sokolowski, Jan" <jan.sokolowski@...el.com>
To: Matthew Wilcox <willy@...radead.org>, Christian König
	<christian.koenig@....com>
CC: "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

So, shall I send a V2 of that patch and add you as co-developer there?

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);