linux-hardening - RE: [RFC] Mitigating unexpected arithmetic overflow

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f41cd250b90d4eb883ea5ff245718200@AcuMS.aculab.com>
Date: Thu, 9 May 2024 21:23:29 +0000
From: David Laight <David.Laight@...LAB.COM>
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-hardening@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"llvm@...ts.linux.dev" <llvm@...ts.linux.dev>
Subject: RE: [RFC] Mitigating unexpected arithmetic overflow

...
> I think that would be a completely different area that might be worth
> looking at: instrumenting implicit casts for "drops bits". I'm afraid
> that it's just *so* common than we might not be able to do that
> sanely.

Things like:
	buf[0] = val;
	buf[1] = val >>= 8;
	buf[2] = val >>= 8;
	buf[3] = val >>= 8;
for writing a value little-endian and potentially misaligned.
Really doesn't want any annotation.

I've also seen code like:
	buf[0] = (unsigned char)(val & 0xff);
not only ugly by it got compiled to:
	val &= 0xff // for the &
	val &= 0xff // for the cast
	byte write to memory.
Modern gcc doesn't do that, but...

There are some spurious casts that drop bits.
I found plenty of dubious min_t(u8/u16,...) examples.
(Well they are dubious, some are just a lot more dubious than others.)
The problem is that every one needs careful inspection just in case
the strange behaviour is required like min_t(u8, val - 1, lo_lim - 1)
which treats lo_lim of zero as 'not a limit' and I think was ok.

A slow, concerted effort to remove min_t() calls wouldn't be a bad thing.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)