linux-kernel - Re: [PATCH v2] hid: logitech: check the return value of create_singlethread

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, 12 Mar 2019 10:02:33 -0600
From:   Jonathan Corbet <corbet@....net>
To:     Kangjie Lu <kjlu@....edu>
Cc:     pakki001@....edu, Jiri Kosina <jikos@...nel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] hid: logitech: check the return value of
 create_singlethread_workqueue

On Tue, 12 Mar 2019 01:16:28 -0500
Kangjie Lu <kjlu@....edu> wrote:

> create_singlethread_workqueue may fail and return NULL. The fix
> checks if it is NULL to avoid NULL pointer dereference.
> Also, the fix moves the call of create_singlethread_workqueue
> earlier to avoid resource-release issues.
> 
> Signed-off-by: Kangjie Lu <kjlu@....edu>

So I don't know this code at all, but...

>  drivers/hid/hid-logitech-hidpp.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index 15ed6177a7a3..1b7c336cae6d 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -2106,6 +2106,12 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 feature_index)
>  	data = kzalloc(sizeof(*data), GFP_KERNEL);
>  	if (!data)
>  		return -ENOMEM;
> +
> +	/* init the hardware command queue */
> +	data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
> +	if (!data->wq)
> +		return -ENOMEM;

It's clear just from the diff that this return will leak 'data'.  You also
break the error handling just below:

>  	data->effect_ids = kcalloc(num_slots, sizeof(int), GFP_KERNEL);
>  	if (!data->effect_ids) {
>  		kfree(data);

It's also worth asking: how are you testing these error path changes?

Thanks,

jon