linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Jonathan Cameron <jic23@cam.ac.uk>,
	Michael Hennerich <michael.hennerich@analog.com>,
	linux-iio@vger.kernel.org,
	device-drivers-devel@blackfin.uclinux.org, drivers@analog.com
Subject: Re: [PATCH] staging:iio:kfifo_buf: Fix potential buffer overflow in iio_read_first_n_kfifo
Date: Thu, 08 Dec 2011 09:14:54 +0000	[thread overview]
Message-ID: <4EE0800E.6010700@kernel.org> (raw)
In-Reply-To: <4EE07FEC.404@kernel.org>

On 12/08/2011 09:14 AM, Jonathan Cameron wrote:
> On 12/07/2011 02:43 PM, Lars-Peter Clausen wrote:
>> n is the number of bytes to read, not the number of samples. So if there is
>> enough data available we will write to the userspace buffer beyond its bounds.
>> Fix this by copying n bytes maximum. Also round n down to the next multiple of
>> the sample size, so we will only read complete samples. If the buffer is too
>> small to hold at least one sample return -EINVAL.
>>
> Dratt. You are quite right.  The documentation for read_first_n is
> rather cryptic.  It was a while ago, but I think the plan was that it
> would be a call to read n scans though clearly it is not in either the
> users or ring_sw.   I guess we might allow partial reads from some
> buffer implementations so probably better this way with the fix in
> the buffer itself as you have done here.   We should also update the
> docs in buffer.h to make it clear it is in bytes rather than 'elements'
> as it currently says.   If you would like to add it to this patch that
> would be great.  I guess I've just been 'lucky' whilst testing this
> buffer...
>> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Doh, forgot I'm not using that email address for acks anymore.
Acked-by: Jonathan Cameron <jic23@kernel.org>

pesky finger memory...
>> ---
>>  drivers/staging/iio/kfifo_buf.c |    6 +++++-
>>  1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/staging/iio/kfifo_buf.c b/drivers/staging/iio/kfifo_buf.c
>> index a64ebbf..930029b 100644
>> --- a/drivers/staging/iio/kfifo_buf.c
>> +++ b/drivers/staging/iio/kfifo_buf.c
>> @@ -161,7 +161,11 @@ static int iio_read_first_n_kfifo(struct iio_buffer *r,
>>  	int ret, copied;
>>  	struct iio_kfifo *kf = iio_to_kfifo(r);
>>  
>> -	ret = kfifo_to_user(&kf->kf, buf, r->bytes_per_datum*n, &copied);
>> +	if (n < r->bytes_per_datum)
>> +		return -EINVAL;
>> +
>> +	n = rounddown(n, r->bytes_per_datum);
>> +	ret = kfifo_to_user(&kf->kf, buf, n, &copied);
>>  
>>  	return copied;
>>  }
> 

  reply	other threads:[~2011-12-08  9:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-07 14:43 [PATCH] staging:iio:kfifo_buf: Fix potential buffer overflow in iio_read_first_n_kfifo Lars-Peter Clausen
2011-12-08  9:14 ` Jonathan Cameron
2011-12-08  9:14   ` Jonathan Cameron [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-12-12  8:33 Lars-Peter Clausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EE0800E.6010700@kernel.org \
    --to=jic23@kernel.org \
    --cc=device-drivers-devel@blackfin.uclinux.org \
    --cc=drivers@analog.com \
    --cc=jic23@cam.ac.uk \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=michael.hennerich@analog.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).