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]
Message-Id: <bfc0de42-a34b-4701-a392-6cbd0061a433@app.fastmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ