linux-kernel - Re: [PATCH] drivers/base/memory: Fix a reference counting issue in __add_memory

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]

Date:   Fri, 22 Apr 2022 10:01:48 +0200
From:   Christophe JAILLET <christophe.jaillet@...adoo.fr>
To:     Michal Hocko <mhocko@...e.com>,
        David Hildenbrand <david@...hat.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Scott Cheloha <cheloha@...ux.vnet.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Nathan Lynch <nathanl@...ux.ibm.com>,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] drivers/base/memory: Fix a reference counting issue in
 __add_memory_block()

Le 22/04/2022 à 09:34, Michal Hocko a écrit :
> On Fri 22-04-22 09:15:21, Christophe JAILLET wrote:
>> There is no point in doing put_device()/device_unregister() on a
>> device that has just been registered a few lines above. This will lead to
>> a double reference decrement.
> 
> This is a bit confusing. I would rephrase.
> "
> __add_memory_block calls both put_device and device_unregister when
> storing the memory block into the xarray. This is incorrect because
> xarray doesn't take an additional reference and device_unregister
> already calls put_device.
> "
> 
> Btw. I do not think this failure path can be triggered, or is there a
> way to hit it?
>   
>> I guess that this put_device()/device_unregister() is a cut'n'paste from
>> remove_memory_block() (i.e. unregister_memory() at the time being) which
>> does need it.
>>
>> Fixes: 4fb6eabf1037 ("drivers/base/memory.c: cache memory blocks in xarray to accelerate lookup")
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
> 
> Other than that looks good to me. With the changelog clarified,
> especially the part that evaluates whether this is a real or a
> theoretical problem, feel free to add
> Acked-by: Michal Hocko <mhocko@...e.com>

I'll send a v2 with the updated changelog.

I do agree that this is certainly a theoretical issue.
Moreover, should it be triggered, I think that it would only print a 
warning message about an erroneous decrement on a ref counted resource 
that is already 0.

Well, it also saves 2 LoC and will look more logical to other readers 
(and static checkers :) )

Thanks for the quick review for both of you.

CJ
> 
> Thanks!
> 
>> ---
>>   drivers/base/memory.c | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
>> index 7222ff9b5e05..084d67fd55cc 100644
>> --- a/drivers/base/memory.c
>> +++ b/drivers/base/memory.c
>> @@ -636,10 +636,9 @@ static int __add_memory_block(struct memory_block *memory)
>>   	}
>>   	ret = xa_err(xa_store(&memory_blocks, memory->dev.id, memory,
>>   			      GFP_KERNEL));
>> -	if (ret) {
>> -		put_device(&memory->dev);
>> +	if (ret)
>>   		device_unregister(&memory->dev);
>> -	}
>> +
>>   	return ret;
>>   }
>>   
>> -- 
>> 2.32.0
>