Message ID | Y0kMh0t5qUXJw3nQ@dc75zzyyyyyyyyyyyyycy-3.rev.dnainternet.fi |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp44030wrs; Fri, 14 Oct 2022 00:19:35 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6P3DY/uEGDpKh7S2QTwOLHGmmmpByMikrDsXua4H1dOBJQfGty3Sr2/BeMXFt84cr0Pmgu X-Received: by 2002:a17:907:948f:b0:78d:e99f:63e3 with SMTP id dm15-20020a170907948f00b0078de99f63e3mr2527813ejc.361.1665731975196; Fri, 14 Oct 2022 00:19:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665731975; cv=none; d=google.com; s=arc-20160816; b=NR5IMy5j5/m/hR6IuFtSpgPrbW4evadsQsxhMf/XfqgJYV9HgVhXj7ZCOIRYVDYmBE taJDdOpOJi3ACLh7ToQbzy5tHZ+gBag22LCCCadZe67KvYlPp6XB8RIV22TFdKWVb+8i 8+4PlfDB/2kliLEK8HVU3+rlo4YNSaS1iWXzVEvmywbbSG/52MaPiZFITHrp2O7iwkhZ ul27upoLHR9LPZ2QPifBhqaZRB2v54BW4eDcmMJzqcN4w3K3CdJh3oMAr1XiG0bivboU oND9OpTpb1kKI/HY7VQbQoc/VuGIm2QMluhhLRsKDpoj2bcn/i2Ii2f6hhH4ig50mIH5 NvGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date:dkim-signature; bh=NGyxzte2IKH3Md6Ogu2BfJvxcJ1+fvLq/yJsfWOfr70=; b=QNmYJglr4lv2foo08qe4LP+zd0+dg5gTyHPJRKASw1OeJ0eqH8Lx2a7MieqQ7rZ/Z9 5T6rpKZXfJXIJZT7rIF81SKD4f+VicsXwXyN2+hRfAZvvvxFw14UJKnn+CAVDUHRuOZC pBqVHDeQfUBDOnO3IEklF3fjiWHbBolmPCXjZ3xVeICVI9QkLk0b07IOd02qyysv6TsW PG+K7V66t+QZdfejTFBJcjYbh35ArjFcs1Vfvl2VMyOnqrFsxu6WIDjUkXWJ2oMYB7pJ RsfEjGLQetiv5+QGxo85ud1Zgp2Xuzg5ZubVWj2WV+PIr/EACYB8abUfZhp5z/KUpgYr SvJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=pqwCFkn2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jz5-20020a170906bb0500b0078bf3d147cdsi1566347ejb.257.2022.10.14.00.19.09; Fri, 14 Oct 2022 00:19:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=pqwCFkn2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229809AbiJNHPr (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Fri, 14 Oct 2022 03:15:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229701AbiJNHPn (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 14 Oct 2022 03:15:43 -0400 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1AEDC510C; Fri, 14 Oct 2022 00:15:40 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id a25so5039732ljk.0; Fri, 14 Oct 2022 00:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=NGyxzte2IKH3Md6Ogu2BfJvxcJ1+fvLq/yJsfWOfr70=; b=pqwCFkn2YfX8+dy9tEFmmFX254tPZhy8XC/gXHWLPWFBChGhNjq3ISmacP2zxKbyFc DZrD/71buQpS8mz6Jk3J4P/Gseqg8DQ9OsFKn0GeflaZzq2mBbQ4pgOyFFjN3Uya/t7r wqlx4VXoWYSp0c9QUis7psazVfZgJOXVie6kCk/CRbSxI/8BDkw6crllLe8SfciZzw1r GHmhItW9sYvjzYsve0MyIVF783NG11UHp+pkLiT7lVgQ93jA/qX5qgpE86BEnvd5UChX 3cDMo7Z3R6/qEwZSRJv9y4z5qgk1OWNPDgbzkLvoHHddloHqKpAqwzYXrV7tFLf4SbF3 41Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NGyxzte2IKH3Md6Ogu2BfJvxcJ1+fvLq/yJsfWOfr70=; b=pyRbCnYn2gckFVJDfl2Fabu3e7nN9riBsbYFrviMdnp4epl6u1hQQyPt23pSlgOpz2 7fnOnNNHq5weyc+f1bApBpZfi/EHqdil7XyNYkazAsfbvYO1hdiN3FSlua9Scre68L+4 e4IoiqzjaS1nE3814HNZj11c6o1fS9FlJwmIbmrptH1JsG150Ie7p6cxHmXsXzvyOWQ5 5tCMUvNEUKuVLliThZKVHuFV2Zo8+iYXXCKvG1ef4NPjABNrFgstRxzO14z9Seq7PzHz OhEAXOp2S984i6Yk88wmbIN2rRtUYxrhOL3613ioORevmsgHNW7GZXZsB7KKADyo/Nxm RmxQ== X-Gm-Message-State: ACrzQf1V7RqMRrVF+nKKvIuqQMZLLf+B+1TCuVDGvfp+4hJ0vjRpHRSI 3JsdXiZRgSw8/d7KXyMOCI71qqF288k= X-Received: by 2002:a05:651c:b23:b0:26f:db39:9544 with SMTP id b35-20020a05651c0b2300b0026fdb399544mr443383ljr.116.1665731738793; Fri, 14 Oct 2022 00:15:38 -0700 (PDT) Received: from dc75zzyyyyyyyyyyyyycy-3.rev.dnainternet.fi (dc75zzyyyyyyyyyyyyycy-3.rev.dnainternet.fi. [2001:14ba:16f3:4a00::4]) by smtp.gmail.com with ESMTPSA id bi19-20020a05651c231300b00261b4df9ec4sm240535ljb.138.2022.10.14.00.15.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Oct 2022 00:15:37 -0700 (PDT) Date: Fri, 14 Oct 2022 10:15:19 +0300 From: Matti Vaittinen <mazziesaccount@gmail.com> To: Matti Vaittinen <mazziesaccount@gmail.com>, Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Cc: Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] =?iso-8859-1?q?=A7tools=3A?= iio: iio_generic_buffer: Fix read size Message-ID: <Y0kMh0t5qUXJw3nQ@dc75zzyyyyyyyyyyyyycy-3.rev.dnainternet.fi> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mOhZbFKr2wlI1FAt" Content-Disposition: inline X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1746646571698237553?= X-GMAIL-MSGID: =?utf-8?q?1746646571698237553?= |
Series |
§tools: iio: iio_generic_buffer: Fix read size
|
|
Commit Message
Matti Vaittinen
Oct. 14, 2022, 7:15 a.m. UTC
When noevents is true and small buffer is used the allocated memory for
holding the data may be smaller than the hard-coded 64 bytes. This can
cause the iio_generic_buffer to crash.
Following was recorded on beagle bone black with v6.0 kernel and the
digit fix patch:
https://lore.kernel.org/all/Y0f+tKCz+ZAIoroQ@dc75zzyyyyyyyyyyyyycy-3.rev.dnainternet.fi/
using valgrind;
==339== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==339== Command: /iio_generic_buffer -n kx022-accel -T0 -e -l 10 -a -w 2000000
==339== Parent PID: 307
==339==
==339== Syscall param read(buf) points to unaddressable byte(s)
==339== at 0x496BFA4: read (read.c:26)
==339== by 0x11699: main (iio_generic_buffer.c:724)
==339== Address 0x4ab3518 is 0 bytes after a block of size 160 alloc'd
==339== at 0x4864B70: malloc (vg_replace_malloc.c:381)
==339== by 0x115BB: main (iio_generic_buffer.c:677)
Fix this by always using the same size for reading as was used for
data storage allocation.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
This patch has been only tested with my kx022a sensor driver. Driver may
have some culprits(s) and my understanding regarding IIO and these tools
is limited so perhaps the hard-coded size of 64 bytes has perfectly
legitimate reason - in which case I would appreciate to hear the
reasoning so I could seek the problem from my driver. Also, I didn't add
the fixes-tag as I don't really know which commit has caused the problem
- as I am not 100% sure what the problem actually is and if I am just
fixing a symptom here.
---
tools/iio/iio_generic_buffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
base-commit: 4fe89d07dcc2804c8b562f6c7896a45643d34b2f
Comments
On Fri, 14 Oct 2022 10:15:19 +0300 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > When noevents is true and small buffer is used the allocated memory for > holding the data may be smaller than the hard-coded 64 bytes. This can > cause the iio_generic_buffer to crash. > > Following was recorded on beagle bone black with v6.0 kernel and the > digit fix patch: > https://lore.kernel.org/all/Y0f+tKCz+ZAIoroQ@dc75zzyyyyyyyyyyyyycy-3.rev.dnainternet.fi/ > using valgrind; > > ==339== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info > ==339== Command: /iio_generic_buffer -n kx022-accel -T0 -e -l 10 -a -w 2000000 > ==339== Parent PID: 307 > ==339== > ==339== Syscall param read(buf) points to unaddressable byte(s) > ==339== at 0x496BFA4: read (read.c:26) > ==339== by 0x11699: main (iio_generic_buffer.c:724) > ==339== Address 0x4ab3518 is 0 bytes after a block of size 160 alloc'd > ==339== at 0x4864B70: malloc (vg_replace_malloc.c:381) > ==339== by 0x115BB: main (iio_generic_buffer.c:677) > > Fix this by always using the same size for reading as was used for > data storage allocation. > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > Huh. I have no idea why that value is 64... And git blame says I wrote it over 10 years ago :) Patch looks fine to me, but given I don't understand the logic of the existing code either I'll leave it on list for a little longer before picking it up. > --- > > This patch has been only tested with my kx022a sensor driver. Driver may > have some culprits(s) and my understanding regarding IIO and these tools > is limited so perhaps the hard-coded size of 64 bytes has perfectly > legitimate reason - in which case I would appreciate to hear the > reasoning so I could seek the problem from my driver. Also, I didn't add > the fixes-tag as I don't really know which commit has caused the problem > - as I am not 100% sure what the problem actually is and if I am just > fixing a symptom here. > --- > tools/iio/iio_generic_buffer.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c > index 2491c54a5e4f..f8deae4e26a1 100644 > --- a/tools/iio/iio_generic_buffer.c > +++ b/tools/iio/iio_generic_buffer.c > @@ -715,12 +715,12 @@ int main(int argc, char **argv) > continue; > } > > - toread = buf_len; > } else { > usleep(timedelay); > - toread = 64; > } > > + toread = buf_len; > + > read_size = read(buf_fd, data, toread * scan_size); > if (read_size < 0) { > if (errno == EAGAIN) { > > base-commit: 4fe89d07dcc2804c8b562f6c7896a45643d34b2f
On Sat, 15 Oct 2022 17:30:14 +0100 Jonathan Cameron <jic23@kernel.org> wrote: > On Fri, 14 Oct 2022 10:15:19 +0300 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > > > When noevents is true and small buffer is used the allocated memory for > > holding the data may be smaller than the hard-coded 64 bytes. This can > > cause the iio_generic_buffer to crash. > > > > Following was recorded on beagle bone black with v6.0 kernel and the > > digit fix patch: > > https://lore.kernel.org/all/Y0f+tKCz+ZAIoroQ@dc75zzyyyyyyyyyyyyycy-3.rev.dnainternet.fi/ > > using valgrind; > > > > ==339== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info > > ==339== Command: /iio_generic_buffer -n kx022-accel -T0 -e -l 10 -a -w 2000000 > > ==339== Parent PID: 307 > > ==339== > > ==339== Syscall param read(buf) points to unaddressable byte(s) > > ==339== at 0x496BFA4: read (read.c:26) > > ==339== by 0x11699: main (iio_generic_buffer.c:724) > > ==339== Address 0x4ab3518 is 0 bytes after a block of size 160 alloc'd > > ==339== at 0x4864B70: malloc (vg_replace_malloc.c:381) > > ==339== by 0x115BB: main (iio_generic_buffer.c:677) > > > > Fix this by always using the same size for reading as was used for > > data storage allocation. > > > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > > > > Huh. I have no idea why that value is 64... And git blame says I wrote it > over 10 years ago :) > > Patch looks fine to me, but given I don't understand the logic of the existing > code either I'll leave it on list for a little longer before picking it up. Guess no one else read this or knows the answer if they did ;) Applied to the fixes-togreg branch of iio.git Thanks, Jonathan > > > > --- > > > > This patch has been only tested with my kx022a sensor driver. Driver may > > have some culprits(s) and my understanding regarding IIO and these tools > > is limited so perhaps the hard-coded size of 64 bytes has perfectly > > legitimate reason - in which case I would appreciate to hear the > > reasoning so I could seek the problem from my driver. Also, I didn't add > > the fixes-tag as I don't really know which commit has caused the problem > > - as I am not 100% sure what the problem actually is and if I am just > > fixing a symptom here. > > --- > > tools/iio/iio_generic_buffer.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c > > index 2491c54a5e4f..f8deae4e26a1 100644 > > --- a/tools/iio/iio_generic_buffer.c > > +++ b/tools/iio/iio_generic_buffer.c > > @@ -715,12 +715,12 @@ int main(int argc, char **argv) > > continue; > > } > > > > - toread = buf_len; > > } else { > > usleep(timedelay); > > - toread = 64; > > } > > > > + toread = buf_len; > > + > > read_size = read(buf_fd, data, toread * scan_size); > > if (read_size < 0) { > > if (errno == EAGAIN) { > > > > base-commit: 4fe89d07dcc2804c8b562f6c7896a45643d34b2f >
diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c index 2491c54a5e4f..f8deae4e26a1 100644 --- a/tools/iio/iio_generic_buffer.c +++ b/tools/iio/iio_generic_buffer.c @@ -715,12 +715,12 @@ int main(int argc, char **argv) continue; } - toread = buf_len; } else { usleep(timedelay); - toread = 64; } + toread = buf_len; + read_size = read(buf_fd, data, toread * scan_size); if (read_size < 0) { if (errno == EAGAIN) {