linux-kernel - Re: [PATCH] staging: pi433: fix race condition in pi433

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: <20180618101838.gzbrxabilnqyilsi@mwanda>
Date:   Mon, 18 Jun 2018 13:18:38 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Hugo Lefeuvre <hle@....eu.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devel@...verdev.osuosl.org,
        Marcus Wolf <linux@...f-entwicklungen.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: pi433: fix race condition in pi433_open

On Sun, Jun 17, 2018 at 10:24:00PM -0400, Hugo Lefeuvre wrote:
> Whenever pi433_open and pi433_remove execute concurrently, a race
> condition potentially resulting in use-after-free might happen.
> 
> Let T1 and T2 be two kernel threads.
> 
> 1. T1 executes pi433_open and stops before "device->users++".
> 2. The pi433 device was removed inbetween, so T2 executes pi433_remove
>    and frees device because the user count has not been incremented yet.
> 3. T1 executes "device->users++" (use-after-free).
> 
> This race condition happens because the check of minor number and
> user count increment does not happen atomically.
> 
> Fix: Extend scope of minor_lock in pi433_open().
> 
> Signed-off-by: Hugo Lefeuvre <hle@....eu.com>
> ---
>  drivers/staging/pi433/pi433_if.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
> index 94e0bfcec991..73c511249f7f 100644
> --- a/drivers/staging/pi433/pi433_if.c
> +++ b/drivers/staging/pi433/pi433_if.c
> @@ -957,11 +957,13 @@ static int pi433_open(struct inode *inode, struct file *filp)
>  
>  	mutex_lock(&minor_lock);
>  	device = idr_find(&pi433_idr, iminor(inode));
> -	mutex_unlock(&minor_lock);
>  	if (!device) {
> +		mutex_unlock(&minor_lock);
>  		pr_debug("device: minor %d unknown.\n", iminor(inode));
>  		return -ENODEV;
>  	}
> +	device->users++;
> +	mutex_unlock(&minor_lock);
>  
>  	if (!device->rx_buffer) {
>  		device->rx_buffer = kmalloc(MAX_MSG_SIZE, GFP_KERNEL);

We need to decrement device->users-- on the error paths as well.
This function was already slightly broken with respect to counting the
users, but let's not make it worse.

I think it's still a tiny bit racy because it's not an atomic type.

I'm not sure the error handling in open() works either.  It's releasing
device->rx_buffer but there could be another user.  The ->rx_buffer
should be allocated in probe() instead of open() probably, no?  And then
freed in pi433_remove().  Then once we put that in the right layer
it means we can just get rid of ->users...

The lines:

  1008                  if (!device->spi)
  1009                          kfree(device);

make no sort of sense at all...  Fortunately it's not posssible for
device->spi to be NULL so it's dead code.

regards,
dan carpenter