Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1526433042.9159.103.camel@codethink.co.uk>
Subject: Re: [PATCH 4.4 125/190] [media] cx25840: fix unchecked return values
From:   Ben Hutchings <ben.hutchings@codethink.co.uk>
To:     Pan Bian <bianpan2016@163.com>,
        Hans Verkuil <hans.verkuil@cisco.com>,
        Mauro Carvalho Chehab <mchehab@s-opensource.com>
Cc:     stable@vger.kernel.org,
        Sasha Levin <alexander.levin@microsoft.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>
Date:   Wed, 16 May 2018 02:10:42 +0100
In-Reply-To: <20180411183559.391845365@linuxfoundation.org>
References: <20180411183550.114495991@linuxfoundation.org>
         <20180411183559.391845365@linuxfoundation.org>
Organization: Codethink Ltd.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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@163.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.