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]
Message-ID: <ad1e9554-ebec-483f-90e0-d0c63fc07b86@google.com>
Date: Thu, 19 Sep 2024 15:50:05 -0700
From: Amit Sunil Dhamne <amitsd@...gle.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
 Greg KH <gregkh@...uxfoundation.org>
Cc: heikki.krogerus@...ux.intel.com, badhri@...gle.com, kyletso@...gle.com,
 rdbabiera@...gle.com, linux-kernel@...r.kernel.org,
 linux-usb@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v1] usb: typec: Fix arg check for
 usb_power_delivery_unregister_capabilities

Hi Greg, Dmitry,

Thanks for the review!

On 9/19/24 3:03 AM, Dmitry Baryshkov wrote:
> On Thu, Sep 19, 2024 at 10:11:37AM GMT, Greg KH wrote:
>> On Thu, Sep 19, 2024 at 12:58:12AM -0700, Amit Sunil Dhamne wrote:
>>> usb_power_delivery_register_capabilities() returns ERR_PTR in case of
>>> failure. usb_power_delivery_unregister_capabilities() we only check
>>> argument ("cap") for NULL. A more robust check would be checking for
>>> ERR_PTR as well.
>>>
>>> Cc: stable@...r.kernel.org
>>> Fixes: 662a60102c12 ("usb: typec: Separate USB Power Delivery from USB Type-C")
>>> Signed-off-by: Amit Sunil Dhamne <amitsd@...gle.com>
>>> Reviewed-by: Badhri Jagan Sridharan <badhri@...gle.com>
>>> ---
>>>   drivers/usb/typec/pd.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/typec/pd.c b/drivers/usb/typec/pd.c
>>> index d78c04a421bc..761fe4dddf1b 100644
>>> --- a/drivers/usb/typec/pd.c
>>> +++ b/drivers/usb/typec/pd.c
>>> @@ -519,7 +519,7 @@ EXPORT_SYMBOL_GPL(usb_power_delivery_register_capabilities);
>>>    */
>>>   void usb_power_delivery_unregister_capabilities(struct usb_power_delivery_capabilities *cap)
>>>   {
>>> -	if (!cap)
>>> +	if (IS_ERR_OR_NULL(cap))
>> This feels like there's a wrong caller, why would this be called with an
>> error value in the first place?  Why not fix that?  And why would this
>> be called with NULL as well in the first place?
> I think passing NULL matches the rest of the kernel, it removes
> unnecessary if(!NULL) statements from the caller side.
>
The reason for this patch was just to be a little more defensive in case 
things slip through cracks and be
consistent with the rest of the PD class. For example 
usb_power_delivery_unregister() &
usb_power_delivery_unlink_device() has similar arg checks.


Regards,

Amit


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ