linux-kernel - Re: [PATCH] iio: avoid fortify-string overflow error

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

Date: Mon, 26 Feb 2024 07:40:18 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jonathan Cameron" <jic23@...nel.org>, "Arnd Bergmann" <arnd@...nel.org>
Cc: "Lars-Peter Clausen" <lars@...afoo.de>,
 "Nathan Chancellor" <nathan@...nel.org>,
 "Nick Desaulniers" <ndesaulniers@...gle.com>,
 "Bill Wendling" <morbo@...gle.com>, "Justin Stitt" <justinstitt@...gle.com>,
 Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH] iio: avoid fortify-string overflow error

On Sun, Feb 25, 2024, at 13:19, Jonathan Cameron wrote:
> On Sat, 24 Feb 2024 13:11:34 +0100 Arnd Bergmann <arnd@...nel.org> wrote:
> It's a false positive, but the compiler has no way to tell that only bits
> 0 and 1 can be set.
> https://lore.kernel.org/linux-iio/20240222222335.work.759-kees@kernel.org/
> for discussion on why + the missing zero initialization bug Kees noticed whilst
> looking at this code.
>
> Kees proposed an alternative way to suppress the warning that I've just applied.
> https://lore.kernel.org/linux-iio/20240223172936.it.875-kees@kernel.org/

Right, that's fine.

> Your solution also works but leaves the implication of a real path to
> overflow the buffer when there isn't one, hence I prefer what Kees had unless
> some future version of clang trips over that in which case we can revisit.

The idea with my patch was to make it obvious to the compiler
that there can't be an overflow, which would ensure the warning
doesn't come back. Kees' version works by avoiding whatever
code path in the compiler trips over the warning, but it's more
likely to come back later if something changes in the compiler
itself, so there is a slight chance that we have it work
around it again.

      Arnd