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@xxxxxxxxxx>
> ---
> 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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
