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] [day] [month] [year] [list]

Message-ID: <414a5ade-3e2c-495d-bbb7-3e721e6897c9@amd.com>
Date: Thu, 27 Nov 2025 16:02:21 +0100
From: Christian König <christian.koenig@....com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Jan Sokolowski <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 11/27/25 15:55, Matthew Wilcox wrote:
> 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.

Oh wow, not every day that we stumble over a bug in such a core kernel functionality.

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

Not sure what it's worth but feel free to add Reviewed-by: Christian König <christian.koenig@....com> to both the test case and the solution.

Thanks for the quick help,
Christian.