linux-kernel - Re: [PATCH] tools: iio: iio_generic_buffer: Fix some integer type and calculation

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>] [day] [month] [year] [list]

Date:   Tue, 25 Jul 2023 09:25:48 +0000
From:   michenyuan <michenyuan@...wei.com>
To:     Jonathan Cameron <jic23@...nel.org>
CC:     "lars@...afoo.de" <lars@...afoo.de>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tools: iio: iio_generic_buffer: Fix some integer type and
 calculation

Chenyuan Mi wrote: 
> Hi,
> 
> In principle I support hardening code, though in this case we are talking about example code only.  We have libiio and similar for anyone who wants to do more than basic tests.
> 
> > In function size_from_channelarray(), the return value 'bytes' is 
> > defined as int type. However, the calcution of 'bytes' in this 
> > function is designed to use the unsigned int type. So it is necessary 
> > to change 'bytes' type to unsigned int to avoid integer overflow.
> 
> For this one, in practice it's controlled entirely by the kernel drivers and they won't get anywhere near integer overflow.  The change is small however and doesn't hurt readability so I guess no harm applying it.
> 
> > 
> > The size_from_channelarray() is called in main() function, its return 
> > value is directly multipled by 'buf_len' and then used as the malloc() parameter.
> > The 'buf_len' is completely controllable by user, thus a 
> > multiplication overflow may occur here. This could allocate an unexpected small area.
> 
> That would have to be a very large allocation...  I suppose it is possible someone might try it...
> 
> > 
> > Signed-off-by: Chenyuan Mi <michenyuan@...wei.com>
> 
> My first inclination is not to apply this on basis that it adds slight complexity to example code (the aim of which is too illustrate the interface), however on the other side of things the checks don't add significant complexity...
> 
> So I tried to apply it, but it doesn't go on cleanly and patch is telling me it's malformed. I'm not quite sure why.
> 
> patching file tools/iio/iio_generic_buffer.c
> patch: **** malformed patch at line 68:                 ret = -ENOMEM;
> 
> Jonathan

I re-send a patch v2, and test patch v2 to make sure it can be applied. Thank you!