linux-kernel - Re: [PATCH v4] HID: ft260: improve error handling of ft260_hid_feature_report

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]

Date:   Tue, 11 May 2021 08:03:22 -0700
From:   Tom Rix <trix@...hat.com>
To:     Michael Zaidman <michael.zaidman@...il.com>
Cc:     jikos@...nel.org, benjamin.tissoires@...hat.com,
        linux-i2c@...r.kernel.org, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] HID: ft260: improve error handling of
 ft260_hid_feature_report_get()


On 5/11/21 7:34 AM, Michael Zaidman wrote:
> On Tue, May 11, 2021 at 06:10:36AM -0700, Tom Rix wrote:
>> Generally change is fine.
>>
>> a nit below.
>>
>> On 5/11/21 3:12 AM, Michael Zaidman wrote:
>>> Fixes: 6a82582d9fa4 ("HID: ft260: add usb hid to i2c host bridge driver")
>>>
>>> The ft260_hid_feature_report_get() checks if the return size matches
>>> the requested size. But the function can also fail with at least -ENOMEM.
>>> Add the < 0 checks.
>>>
>>> In ft260_hid_feature_report_get(), do not do the memcpy to the caller's
>>> buffer if there is an error.
>>>
>>> ---
>>> v4   Fixed commit message
>>> ---
>>> v3   Simplify and optimize the changes
>>> ---
>>> v2:  add unlikely()'s for error conditions
>>> ---
>>>
>>> Signed-off-by: Tom Rix <trix@...hat.com>
>>> Signed-off-by: Michael Zaidman <michael.zaidman@...il.com>
>>> ---
>>>    drivers/hid/hid-ft260.c | 24 ++++++++++++------------
>>>    1 file changed, 12 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
>>> index 047aa85a7c83..7f4cb823129e 100644
>>> --- a/drivers/hid/hid-ft260.c
>>> +++ b/drivers/hid/hid-ft260.c
>>> @@ -249,7 +249,10 @@ static int ft260_hid_feature_report_get(struct hid_device *hdev,
>>>    	ret = hid_hw_raw_request(hdev, report_id, buf, len, HID_FEATURE_REPORT,
>>>    				 HID_REQ_GET_REPORT);
>>> -	memcpy(data, buf, len);
>>> +	if (likely(ret == len))
>>> +		memcpy(data, buf, len);
>>> +	else if (ret >= 0)
>>> +		ret = -EIO;
>>>    	kfree(buf);
>>>    	return ret;
>>>    }
>>> @@ -298,7 +301,7 @@ static int ft260_xfer_status(struct ft260_device *dev)
>>>    	ret = ft260_hid_feature_report_get(hdev, FT260_I2C_STATUS,
>>>    					   (u8 *)&report, sizeof(report));
>>> -	if (ret < 0) {
>>> +	if (unlikely(ret < 0)) {
>>>    		hid_err(hdev, "failed to retrieve status: %d\n", ret);
>>>    		return ret;
>>>    	}
>>> @@ -720,10 +723,9 @@ static int ft260_get_system_config(struct hid_device *hdev,
>>>    	ret = ft260_hid_feature_report_get(hdev, FT260_SYSTEM_SETTINGS,
>>>    					   (u8 *)cfg, len);
>>> -	if (ret != len) {
>>> +	if (ret < 0) {
>> nit: should be consistent and use unlikely(ret < 0) for this and other
>> similar checks.
>>
>> Tom
> I preserved the likely/unlikely hints in the critical path where the
> performance matters. And for the sake of consistency, I removed them from
> the rest of the places that are called rarely and are not performance-critical
> to be aligned to the other "if" statements in the code.

This is fine.

Thanks,

Tom

>
> Michael
>