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: <06dbd4f8-ef5f-458c-a8b4-8a8fb2a7877c@amd.com>
Date: Thu, 27 Nov 2025 15:03:20 +0100
From: Christian König <christian.koenig@....com>
To: Matthew Wilcox <willy@...radead.org>,
 Jan Sokolowski <jan.sokolowski@...el.com>
Cc: 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 14:54, Matthew Wilcox wrote:
> On Thu, Nov 27, 2025 at 10:27:32AM +0100, Jan Sokolowski wrote:
>> A scenario was found where trying to add id in range 0,1
>> would return an id of 2, which is outside the range and thus
>> now what the user would expect.
> 
> Can you do a bit better with this bug report?  Under what circumstances
> does this happen?  Preferably answer in the form of a test case for the
> IDR test suite.  Here's my attempt to recreate your situation based on
> what I read in that thread.  It doesn't show a problem, so clearly I got
> something wrong.

According to Jan the observation he has is that this code:

idr_init_base(&idr, 1);
id = idr_alloc(&idr, dummy_ptr, 0, 1, GFP_KERNEL);

Gives him id=2 in return.

That clearly seems to be problematic considering that start=0 and end=1 should either give you id=0 or an error because idr->idr_base should be initialized to 1.

But I'm still not sure if Jan's observation is actually correct, cause I also don't see how that possible happen.

Regards,
Christian.

> To run the test suite, apply this patch, then
> 
> $ make -C tools/testing/radix-tree
> $ ./tools/testing/radix-tree/idr-test
> 
> diff --git a/tools/testing/radix-tree/idr-test.c b/tools/testing/radix-tree/idr-test.c
> index 2f830ff8396c..774c0c9c141f 100644
> --- a/tools/testing/radix-tree/idr-test.c
> +++ b/tools/testing/radix-tree/idr-test.c
> @@ -57,6 +57,21 @@ void idr_alloc_test(void)
>  	idr_destroy(&idr);
>  }
>  
> +void idr_alloc2_test(void)
> +{
> +	int id;
> +	DEFINE_IDR(idr);
> +
> +	id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL);
> +	printf("id = %d\n", id);
> +	assert(id == 0);
> +	id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL);
> +	printf("id = %d\n", id);
> +	assert(id == -ENOSPC);
> +
> +	idr_destroy(&idr);
> +}
> +
>  void idr_replace_test(void)
>  {
>  	DEFINE_IDR(idr);
> @@ -409,6 +424,7 @@ void idr_checks(void)
>  
>  	idr_replace_test();
>  	idr_alloc_test();
> +	idr_alloc2_test();
>  	idr_null_test();
>  	idr_nowait_test();
>  	idr_get_next_test(0);


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ