linux-kernel - Re: [PATCH 4.4 125/190] [media] cx25840: fix unchecked return values

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: <1526433042.9159.103.camel@codethink.co.uk>
Date:   Wed, 16 May 2018 02:10:42 +0100
From:   Ben Hutchings <ben.hutchings@...ethink.co.uk>
To:     Pan Bian <bianpan2016@....com>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Mauro Carvalho Chehab <mchehab@...pensource.com>
Cc:     stable@...r.kernel.org,
        Sasha Levin <alexander.levin@...rosoft.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4.4 125/190] [media] cx25840: fix unchecked return values

On Wed, 2018-04-11 at 20:36 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Pan Bian <bianpan2016@....com>
> 
> 
> [ Upstream commit 35378ce143071c2a6bad4b59a000e9b9f8f6ea67 ]
> 
> In functions cx25840_initialize(), cx231xx_initialize(), and
> cx23885_initialize(), the return value of create_singlethread_workqueue()
> is used without validation. This may result in NULL dereference and cause
> kernel crash. This patch fixes it.
[...]
> --- a/drivers/media/i2c/cx25840/cx25840-core.c
> +++ b/drivers/media/i2c/cx25840/cx25840-core.c
> @@ -420,11 +420,13 @@ static void cx25840_initialize(struct i2
>  	INIT_WORK(&state->fw_work, cx25840_work_handler);
>  	init_waitqueue_head(&state->fw_wait);
>  	q = create_singlethread_workqueue("cx25840_fw");
> -	prepare_to_wait(&state->fw_wait, &wait, TASK_UNINTERRUPTIBLE);
> -	queue_work(q, &state->fw_work);
> -	schedule();
> -	finish_wait(&state->fw_wait, &wait);
> -	destroy_workqueue(q);
> +	if (q) {
> +		prepare_to_wait(&state->fw_wait, &wait, TASK_UNINTERRUPTIBLE);
> +		queue_work(q, &state->fw_work);
> +		schedule();
> +		finish_wait(&state->fw_wait, &wait);
> +		destroy_workqueue(q);
> +	}
[...]

Why is the error "handled" by skipping part of the initialisation
process?  Shouldn't we abort and return an error?

Why even create a private workqueue, when we don't do anything that
wouldn't work with one of the global workqueues?

Why even use a workqueue, if we immediately block waiting for the work
to finish?  This makes no sense to me.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.