linux-kernel - Re: [PATCH] iio: buffer: fix use-after-free for attached

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: <20210307123658.3bdc0016@archlinux>
Date:   Sun, 7 Mar 2021 12:36:58 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Alexandru Ardelean <ardeleanalex@...il.com>
Cc:     linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Lars-Peter Clausen <lars@...afoo.de>
Subject: Re: [PATCH] iio: buffer: fix use-after-free for attached_buffers
 array

On Sat,  6 Mar 2021 18:47:10 +0200
Alexandru Ardelean <ardeleanalex@...il.com> wrote:

> Thanks to Lars for finding this.
> The free of the 'attached_buffers' array should be done as late as
> possible. This change moves it to iio_buffers_put(), which looks like
> the best place for it, since it takes place right before the IIO device
> data is free'd.

It feels a bit wrong to do direct freeing of stuff in a _put() call
given that kind of implies nothing will happen without some reference
count dropping to 0.  We could think about renaming the function to
something like

iio_buffers_put_and_free_array() but is a bit long winded.

Otherwise, I'm fine with this but want to let it sit on list a tiny bit
longer before I take it as it's not totally trivial unlike the previous
one.

Jonathan
> The free of this array will be handled by calling iio_device_free().
> 
> It looks like this issue was ocurring on the error path of
> iio_buffers_alloc_sysfs_and_mask() and in
> iio_buffers_free_sysfs_and_mask()
> 
> Added a comment in the doc-header of iio_device_attach_buffer() to
> mention how this will be free'd in case anyone is reading the code
> and becoming confused about it.
> 
> Fixes: 36f3118c414d ("iio: buffer: introduce support for attaching more IIO buffers")
> Reported-by: Lars-Peter Clausen <lars@...afoo.de>
> Signed-off-by: Alexandru Ardelean <ardeleanalex@...il.com>
> ---
>  drivers/iio/industrialio-buffer.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
> index 1a415e97174e..3d0712651d43 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -336,6 +336,8 @@ void iio_buffers_put(struct iio_dev *indio_dev)
>  		buffer = iio_dev_opaque->attached_buffers[i];
>  		iio_buffer_put(buffer);
>  	}
> +
> +	kfree(iio_dev_opaque->attached_buffers);
>  }
>  
>  static ssize_t iio_show_scan_index(struct device *dev,
> @@ -1764,7 +1766,6 @@ int iio_buffers_alloc_sysfs_and_mask(struct iio_dev *indio_dev)
>  		buffer = iio_dev_opaque->attached_buffers[unwind_idx];
>  		__iio_buffer_free_sysfs_and_mask(buffer);
>  	}
> -	kfree(iio_dev_opaque->attached_buffers);
>  	return ret;
>  }
>  
> @@ -1786,8 +1787,6 @@ void iio_buffers_free_sysfs_and_mask(struct iio_dev *indio_dev)
>  		buffer = iio_dev_opaque->attached_buffers[i];
>  		__iio_buffer_free_sysfs_and_mask(buffer);
>  	}
> -
> -	kfree(iio_dev_opaque->attached_buffers);
>  }
>  
>  /**
> @@ -2062,6 +2061,8 @@ static int iio_buffer_mmap(struct file *filep, struct vm_area_struct *vma)
>   * This function attaches a buffer to a IIO device. The buffer stays attached to
>   * the device until the device is freed. For legacy reasons, the first attached
>   * buffer will also be assigned to 'indio_dev->buffer'.
> + * The array allocated here, will be free'd via the iio_buffers_put() call,
> + * which is handled by the iio_device_free().
>   */
>  int iio_device_attach_buffer(struct iio_dev *indio_dev,
>  			     struct iio_buffer *buffer)