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: <47c7694c-25e1-4fe1-ae3c-855178d3d065@gmail.com>
Date: Mon, 14 Oct 2024 09:59:49 +0200
From: Javier Carrasco <javier.carrasco.cruz@...il.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: 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>, Umang Jain <umang.jain@...asonboard.com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 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 14/10/2024 09:22, Dan Carpenter wrote:
> On Sun, Oct 13, 2024 at 12:42:32PM +0200, 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");
>>  	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");
> 
> Perhaps it's better to declare the variable here so that the function and the
> error handling are next to each other.
> 
> 	if (!info)
> 		return -EINVAL;
> 
> 	struct device_node *fw_node __free(device_node) =
> 		of_find_compatible_node(NULL, NULL, "raspberrypi,bcm2835-firmware");
> 	if (!fw_node) {
> 
> 	...
> 
> This is why we lifted the rule that variables had to be declared at the start
> of a function.
> 
> regards,
> dan carpenter
> 

This approach is great as long as the maintainer accepts mid-scope
variable declaration and the goto instructions get refactored, as stated
in cleanup.h.

The first point is not being that problematic so far, but the second one
is trickier, and we all have to take special care to avoid such issues,
even if they don't look dangerous in the current code, because adding a
goto where there cleanup attribute is already used can be overlooked as
well.

Actually there are goto instructions in the function, but at least in
their current form they are as harmless as useless. I will refactor them
anyway in another patch to stick to the recommendations, and declare the
device_node right before its first usage for v2.

Thanks and best regards,
Javier Carrasco

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ