Re: [PATCH] iio: buffer: fix use-after-free for attached_buffers array

2021-03-07 Thread Alexandru Ardelean
On Sun, Mar 7, 2021 at 2:54 PM Lars-Peter Clausen  wrote:
>
> On 3/7/21 1:36 PM, Jonathan Cameron wrote:
> > On Sat,  6 Mar 2021 18:47:10 +0200
> > Alexandru Ardelean  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.
>
> Maybe to go with naming schema of iio_device_attach_buffer() call this
> function iio_device_detach_buffers(). We grab the reference in attach,
> and drop it in detach.

That actually sounds like it fits beautifully ( the
iio_device_detach_buffers() name ).
Thanks for the hint.

I'll send a V2.
I didn't consider more on the renaming of iio_buffers_put() because I
was a bit stressed by the silliness of the use-after-free bug.

Thanks
Alex

>
> - Lars
>


Re: [PATCH] iio: buffer: fix use-after-free for attached_buffers array

2021-03-07 Thread Lars-Peter Clausen

On 3/7/21 1:36 PM, Jonathan Cameron wrote:

On Sat,  6 Mar 2021 18:47:10 +0200
Alexandru Ardelean  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.


Maybe to go with naming schema of iio_device_attach_buffer() call this 
function iio_device_detach_buffers(). We grab the reference in attach, 
and drop it in detach.


- Lars



Re: [PATCH] iio: buffer: fix use-after-free for attached_buffers array

2021-03-07 Thread Jonathan Cameron
On Sat,  6 Mar 2021 18:47:10 +0200
Alexandru Ardelean  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 
> Signed-off-by: Alexandru Ardelean 
> ---
>  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)



[PATCH] iio: buffer: fix use-after-free for attached_buffers array

2021-03-06 Thread Alexandru Ardelean
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.
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 
Signed-off-by: Alexandru Ardelean 
---
 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)
-- 
2.25.1