[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ff5abac97c7549d392674ce09cd970c5@AcuMS.aculab.com>
Date: Mon, 14 Feb 2022 17:16:06 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Solar Designer' <solar@...nwall.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Alexey Gladkov" <legion@...nel.org>,
Kees Cook <keescook@...omium.org>,
Shuah Khan <shuah@...nel.org>,
Christian Brauner <brauner@...nel.org>,
Ran Xiaokai <ran.xiaokai@....com.cn>,
Michal Koutn?? <mkoutny@...e.com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH 5/8] ucounts: Handle wrapping in is_ucounts_overlimit
From: Solar Designer
> Sent: 12 February 2022 22:37
...
> bool is_ucounts_overlimit(struct ucounts *ucounts, enum ucount_type type, unsigned long rlimit)
> {
> struct ucounts *iter;
> long max = rlimit;
> if (rlimit > LONG_MAX)
> max = LONG_MAX;
>
> The assignment on "long max = rlimit;" would have already been UB if
> "rlimit > LONG_MAX", which is only checked afterwards. I think the
> above would be better written as:
I'm pretty sure assignments and casts of negative values to unsigned
types are actually well defined.
Although the actual value may differ for ones-compliment and
sign-overpunch systems.
But I suspect Linux requires twos-compliment negative numbers.
(In much the same way as it requires that NULL be the all zero
bit pattern - although a load of annoying compiler warnings are only
relevant if that isn't the case.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists