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: <fc10d4ac-8ad0-4756-8d65-8700aa7f8f21@gmail.com>
Date: Sat, 21 Dec 2024 16:59:31 +0530
From: Nihar Chaithanya <niharchaithanya@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: dpenkler@...il.com, dan.carpenter@...aro.org, roheetchavan@...il.com,
 arnd@...db.de, linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
 skhan@...uxfoundation.org
Subject: Re: [PATCH v2] staging: gpib: cb7210: Add error handling


On 21/12/24 15:13, Greg KH wrote:
> On Sat, Dec 21, 2024 at 10:25:41AM +0100, Greg KH wrote:
>> On Sat, Dec 21, 2024 at 02:41:25PM +0530, Nihar Chaithanya wrote:
>>> The if condition in cb7210_init_module() would always fail as
>>> the value of err is constantly 0. The function
>>> cb_pcmcia_init_module() can be refactored into a single line,
>>> and can be replaced entirely with pcmcia_register_driver().
>>>
>>> Replace redundant cb_pcmcia_init_module() with
>>> pcmcia_register_driver() which returns appropriate error code if
>>> it fails. Handle the error if it fails and print the debug message.
>>>
>>> This issue was reported by Coverity Scan.
>>> Report:
>>> CID 1635894: (#1 of 1): 'Constant' variable guards dead code (DEADCODE)
>>> dead_error_line: Execution cannot reach this statement: return -1;.
>>>
>>> Signed-off-by: Nihar Chaithanya <niharchaithanya@...il.com>
>>> ---
>>> v1 --> v2: Replaced the redundant cb_pcmcia_init_module() with
>>> 	   pcmcia_register_driver().
>>>
>>>   drivers/staging/gpib/cb7210/cb7210.c | 13 ++++---------
>>>   1 file changed, 4 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/staging/gpib/cb7210/cb7210.c b/drivers/staging/gpib/cb7210/cb7210.c
>>> index 63df7f3eb3f3..abd6632d8448 100644
>>> --- a/drivers/staging/gpib/cb7210/cb7210.c
>>> +++ b/drivers/staging/gpib/cb7210/cb7210.c
>>> @@ -1351,12 +1351,6 @@ static struct pcmcia_driver cb_gpib_cs_driver = {
>>>   	.resume		= cb_gpib_resume,
>>>   };
>>>   
>>> -int cb_pcmcia_init_module(void)
>>> -{
>>> -	pcmcia_register_driver(&cb_gpib_cs_driver);
>>> -	return 0;
>>> -}
>>> -
>>>   void cb_pcmcia_cleanup_module(void)
>>>   {
>>>   	DEBUG(0, "cb_gpib_cs: unloading\n");
>>> @@ -1526,11 +1520,12 @@ static int __init cb7210_init_module(void)
>>>   	gpib_register_driver(&cb_pcmcia_interface, THIS_MODULE);
>>>   	gpib_register_driver(&cb_pcmcia_accel_interface, THIS_MODULE);
>>>   	gpib_register_driver(&cb_pcmcia_unaccel_interface, THIS_MODULE);
>>> -	err += cb_pcmcia_init_module();
>>> +	err = pcmcia_register_driver(&cb_gpib_cs_driver);
>>>   #endif
>>> -	if (err)
>>> +	if (err) {
>>> +		pr_err("cb7210: registering PCMCIA driver with the bus core failed\n");
>>>   		return -1;
>> Not your issue, but "-1" is not a valid error number, shouldn't this be
>> returning a real error (i.e. the one that was returned?)
>>
>> And err += is crazy, thanks for removing that, BUT you forgot to unwind
>> the previous functions so now if pcmcia_register_driver() fails, you
>> have a semi-registered system and then the module will unload (as init
>> fails) and bad things will happen :(
So I need be unregistering the driver if the pcmcia_register_driver() fails
right?
>> So you kind of just made the code worse overall, not better, which
>> really isn't a good idea for a "bugfix" that covertity was trying to
>> point out.
> And (this is taking you down a path that is much larger than you
> expected to just fix this one issue, sorry), it looks like
> gpib_register_driver() can fail, so it MUST return an error value so you
> can properly unwind from it.  So that too needs to be fixed up here
> (also minor nit, gpib_register_driver() should not be calling pr_info(),
> but that's a different issue.)
Yes Greg, gpib_register_driver() should be returning -ENOMEM if it fails,
thank you for pointing it out, I'll change the gpib code wherever the
drivers are registered, I'll send the patch as soon as I can.
> In all, there are loads of tiny things like this to fix up in the gpib
> code, which is great, have fun!
yes, I am happy to contribute.
> thanks,
>
> greg k-h
thank you,
Nihar

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ