[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1351354318.4834.7.camel@deadeye.wl.decadent.org.uk>
Date: Sat, 27 Oct 2012 17:11:58 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: Fengguang Wu <fengguang.wu@...el.com>,
Kees Cook <keescook@...omium.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
alan@...rguk.ukuu.org.uk,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [ 16/85] use clamp_t in UNAME26 fix
On Thu, 2012-10-25 at 17:05 -0700, Greg Kroah-Hartman wrote:
> 3.6-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Kees Cook <keescook@...omium.org>
>
> commit 31fd84b95eb211d5db460a1dda85e004800a7b52 upstream.
>
> The min/max call needed to have explicit types on some architectures
> (e.g. mn10300). Use clamp_t instead to avoid the warning:
>
> kernel/sys.c: In function 'override_release':
> kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default]
While this change makes the code more readable, I think the bug is
really in the type definitions for those architectures:
[...]
> - copy = min(sizeof(buf), max_t(size_t, 1, len));
> + copy = clamp_t(size_t, len, 1, sizeof(buf));
[...]
1. sizeof(buf) yields a value of type size_t, by definition.
2. max_t(size_t, 1, len) yields a value of type size_t.
3. Therefore min(sizeof(buf), max_t(size_t, 1, len)) is valid.
The only way I see to get this warning is to define size_t wrongly, so
that (1) is not true.
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists