linux-kernel - Re: [PATCH] xarray: Add a BUG_ON() to ensure caller is not sibling

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: <8fb366e2-cec2-42ba-97c4-2d927423a26e@arm.com>
Date: Fri, 30 May 2025 09:14:01 +0530
From: Dev Jain <dev.jain@....com>
To: Zi Yan <ziy@...dia.com>
Cc: akpm@...ux-foundation.org, willy@...radead.org,
 linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, david@...hat.com, anshuman.khandual@....com,
 ryan.roberts@....com
Subject: Re: [PATCH] xarray: Add a BUG_ON() to ensure caller is not sibling


On 30/05/25 4:17 am, Zi Yan wrote:
> On 28 May 2025, at 23:17, Dev Jain wrote:
>
>> On 28/05/25 10:42 pm, Zi Yan wrote:
>>> On 28 May 2025, at 7:31, Dev Jain wrote:
>>>
>>>> Suppose xas is pointing somewhere near the end of the multi-entry batch.
>>>> Then it may happen that the computed slot already falls beyond the batch,
>>>> thus breaking the loop due to !xa_is_sibling(), and computing the wrong
>>>> order. Thus ensure that the caller is aware of this by triggering a BUG
>>>> when the entry is a sibling entry.
>>> Is it possible to add a test case in lib/test_xarray.c for this?
>>> You can compile the tests with “make -C tools/testing/radix-tree”
>>> and run “./tools/testing/radix-tree/xarray”.
>>
>> Sorry forgot to Cc you.
>> I can surely do that later, but does this patch look fine?
> I am not sure the exact situation you are describing, so I asked you
> to write a test case to demonstrate the issue. :)


Suppose we have a shift-6 node having an order-9 entry => 8 - 1 = 7 siblings,
so assume the slots are at offset 0 till 7 in this node. If xas->xa_offset is 6,
then the code will compute order as 1 + xas->xa_node->shift = 7. So I mean to
say that the order computation must start from the beginning of the multi-slot
entries, that is, the non-sibling entry.


>
>>
>>>> This patch is motivated by code inspection and not a real bug report.
>>>>
>>>> Signed-off-by: Dev Jain <dev.jain@....com>
>>>> ---
>>>> The patch applies on 6.15 kernel.
>>>>
>>>>    lib/xarray.c | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/lib/xarray.c b/lib/xarray.c
>>>> index 9644b18af18d..0f699766c24f 100644
>>>> --- a/lib/xarray.c
>>>> +++ b/lib/xarray.c
>>>> @@ -1917,6 +1917,8 @@ int xas_get_order(struct xa_state *xas)
>>>>    	if (!xas->xa_node)
>>>>    		return 0;
>>>>
>>>> +	XA_NODE_BUG_ON(xas->xa_node, xa_is_sibling(xa_entry(xas->xa,
>>>> +		       xas->xa_node, xas->xa_offset)));
>>>>    	for (;;) {
>>>>    		unsigned int slot = xas->xa_offset + (1 << order);
>>>>
>>>> -- 
>>>> 2.30.2
>>> Best Regards,
>>> Yan, Zi
>
> Best Regards,
> Yan, Zi