linux-kernel - Re: [PATCH] staging: vchiq_arm: Fix missing refcount decrement in error path for fw

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4c190f41-eac4-4dfa-8667-368f57b9f445@gmail.com>
Date: Sun, 13 Oct 2024 14:55:30 +0200
From: Javier Carrasco <javier.carrasco.cruz@...il.com>
To: Umang Jain <umang.jain@...asonboard.com>,
 Florian Fainelli <florian.fainelli@...adcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Stefan Wahren <wahrenst@....net>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: linux-rpi-kernel@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, linux-staging@...ts.linux.dev,
 linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] staging: vchiq_arm: Fix missing refcount decrement in
 error path for fw_node

On 13/10/2024 13:36, Umang Jain wrote:
> Hi Javier,
> 
> Thank you for the patch.
> 
> On 13/10/24 4:12 pm, Javier Carrasco wrote:
>> An error path was introduced without including the required call to
>> of_node_put() to decrement the node's refcount and avoid leaking memory.
>> If the call to kzalloc() for 'mgmt' fails, the probe returns without
>> decrementing the refcount.
>>
>> Use the automatic cleanup facility to fix the bug and protect the code
>> against new error paths where the call to of_node_put() might be missing
>> again.
>>
>> Cc: stable@...r.kernel.org
>> Fixes: 1c9e16b73166 ("staging: vc04_services: vchiq_arm: Split driver
>> static and runtime data")
>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@...il.com>
>> ---
>>   drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 6 +
>> +----
>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/
>> vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/
>> vchiq_arm.c
>> index 27ceaac8f6cc..792cf3a807e1 100644
>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>> @@ -1332,7 +1332,8 @@ MODULE_DEVICE_TABLE(of, vchiq_of_match);
>>     static int vchiq_probe(struct platform_device *pdev)
>>   {
>> -    struct device_node *fw_node;
>> +    struct device_node *fw_node __free(device_node) =
>> +        of_find_compatible_node(NULL, NULL, "raspberrypi,bcm2835-
>> firmware");
> 
> How about :
> 
> +    struct device_node *fw_node __free(device_node) = NULL;
> 
>>       const struct vchiq_platform_info *info;
>>       struct vchiq_drv_mgmt *mgmt;
>>       int ret;
>> @@ -1341,8 +1342,6 @@ static int vchiq_probe(struct platform_device
>> *pdev)
>>       if (!info)
>>           return -EINVAL;
>>   -    fw_node = of_find_compatible_node(NULL, NULL,
>> -                      "raspberrypi,bcm2835-firmware");
> 
> And undo this (i.e. keep the of_find_compatible_node() call here
> 
> This helps with readability as there is a NULL check just after this.
>>       if (!fw_node) {
>>           dev_err(&pdev->dev, "Missing firmware node\n");
>>           return -ENOENT;
>> @@ -1353,7 +1352,6 @@ static int vchiq_probe(struct platform_device
>> *pdev)
>>           return -ENOMEM;
>>         mgmt->fw = devm_rpi_firmware_get(&pdev->dev, fw_node);
>> -    of_node_put(fw_node);
> 
> And this change remains the same.
>>       if (!mgmt->fw)
>>           return -EPROBE_DEFER;
>>  
>> ---
>> base-commit: d61a00525464bfc5fe92c6ad713350988e492b88
>> change-id: 20241013-vchiq_arm-of_node_put-60a5eaaafd70
>>
>> Best regards,
> 


Hi Umang,

Sure, I am fine with that too.

Depending on the maintainer, the preferred approach varies: a single
initialization at the top whenever possible, a declaration right before
its first usage (not my favorite), or a NULL initialization first. I
will send a v2 with the latter i.e. what you suggested, as it keeps
everything more similar to what it used to be.

Thanks and best regards,
Javier Carrasco