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] [thread-next>] [day] [month] [year] [list]
Message-ID: <59f731ab619673afec4956fce6832a1cd5324fb8.camel@tugraz.at>
Date: Sun, 12 May 2024 10:03:30 +0200
From: Martin Uecker <uecker@...raz.at>
To: Linus Torvalds <torvalds@...ux-foundation.org>, Kees Cook
	 <keescook@...omium.org>
Cc: Justin Stitt <justinstitt@...gle.com>, Peter Zijlstra
 <peterz@...radead.org>,  Mark Rutland <mark.rutland@....com>,
 linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org, 
 llvm@...ts.linux.dev
Subject: Re: [RFC] Mitigating unexpected arithmetic overflow

Am Mittwoch, dem 08.05.2024 um 16:47 -0700 schrieb Linus Torvalds:
> On Wed, 8 May 2024 at 15:54, Kees Cook <keescook@...omium.org> wrote:
> > 
...
> 
> No, the only point where that actually failed was then when a
> (non-overflowing, non-wrapping) final value was assigned to a 16-bit
> field, ie the problem only ever happened at the final assignment:
> 
>         event->read_size = size;
> 
> where no overflow had ever happened before that.
> 
> So in *that* case, you actually have a much more interesting
> situation. Not wrap-around, not overflow, but "implicit cast drops
> significant bits".
> 
> And yes, I do think implicit integer casts are dangerous. Often *more*
> dangerous than arithmetic overflow and wrapping. We've had absolutely
> tons of them. Some of our most traditional bugs have very much been
> about implicit casting losing bits and causing problems as a result.

In principle, GCC has -Wconversions which looks like that it is
meant to catch this.  It seems not entirely stupid, e.g. it warns 
about  the first assignment and not the second (x86):

void f(int i)
{
    unsigned short y = i;
    unsigned short x = i & 0xFFF;
}

But I guess it still could be smarter. Or does it have to be a
sanitizer because compile-time will always have too many false 
positives?

Martin




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ