[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <196c1592-3383-409a-8b4e-38ef1c215528@linux.ibm.com>
Date: Thu, 18 Sep 2025 12:15:52 +0530
From: Donet Tom <donettom@...ux.ibm.com>
To: David Hildenbrand <david@...hat.com>, akpm@...ux-foundation.org,
clm@...a.com
Cc: Jonathan.Cameron@...wei.com, alison.schofield@...el.com, dakr@...nel.org,
dave.jiang@...el.com, gregkh@...uxfoundation.org,
kamezawa.hiroyu@...fujitsu.com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, osalvador@...e.de, rafael@...nel.org,
ritesh.list@...il.com, yury.norov@...il.com, ziy@...dia.com
Subject: Re: [PATCH] drivers/base/node: Fix double free in register_one_node()
On 9/18/25 11:25 AM, David Hildenbrand wrote:
> On 18.09.25 07:41, Donet Tom wrote:
>> When device_register() fails in register_node(), it calls
>> put_device(&node->dev). This triggers node_device_release(),
>> which calls kfree(to_node(dev)), thereby freeing the entire
>> node structure.
>>
>> As a result, when register_node() returns an error, the node
>> memory has already been freed. Calling kfree(node) again in
>> register_one_node() leads to a double free.
>>
>> This patch removes the redundant kfree(node) from
>> register_one_node() to prevent the double free.
>>
>> Fixes: 786eb990cfb7 ("drivers/base/node: handle error properly in
>> register_one_node()")
>> Signed-off-by: Donet Tom <donettom@...ux.ibm.com>
>> ---
>> drivers/base/node.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/base/node.c b/drivers/base/node.c
>> index 1608816de67f..6b6e55a98b79 100644
>> --- a/drivers/base/node.c
>> +++ b/drivers/base/node.c
>> @@ -885,7 +885,6 @@ int register_one_node(int nid)
>> error = register_node(node_devices[nid], nid);
>> if (error) {
>> node_devices[nid] = NULL;
>> - kfree(node);
>> return error;
>> }
>
> Yes, that matches what other users (staring at mm/memory-tiers.c) do.
>
> I wonder if we should just inline register_node() into
> register_one_node().
>
> Then it's clearer that we perform a put_device() already in there.
>
> On top of that, we could then just s/register_one_node/register_node/
>
> And then we could do a similar cleanup for unregister_one_node /
> unregister_node where I don't consider the split function really
> valuable.
Sure David, I will work on it and send it as a separate patch.
Powered by blists - more mailing lists