From: Xi Wang <xi.wang@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: Jason Baron <jbaron@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>, Xi Wang <xi.wang@gmail.com>
Subject: [PATCH RFC] exec: avoid possible undefined behavior in count()
Date: Sun, 6 Jan 2013 00:29:05 -0500 [thread overview]
Message-ID: <1357450145-23964-1-git-send-email-xi.wang@gmail.com> (raw)
The tricky problem is this check:
if (i++ >= max)
icc (mis)optimizes this check as:
if (++i > max)
The check now becomes a no-op since max is MAX_ARG_STRINGS (0x7FFFFFFF).
This is "allowed" by the C standard, assuming i++ never overflows,
because signed integer overflow is undefined behavior. This optimization
effectively reverts the previous commit 362e6663ef ("exec.c, compat.c:
fix count(), compat_count() bounds checking") that tries to fix the check.
This patch simply moves ++ after the check.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
---
Not sure how many people are using Intel's icc to compiled the kernel.
Some projects like LinuxDNA did.
The kernel uses gcc's -fno-strict-overflow to disable this optimization.
icc probably doesn't recognize the option.
To illustrate the problem, try this simple program:
int count(int i, int max)
{
if (i++ >= max) {
__builtin_trap();
return -1;
}
return i;
}
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
int x = atoi(argv[1]);
int max = atoi(argv[2]);
printf("%d %d %d\n", x, max, count(x, max));
}
$ gcc -O2 t.c
$ ./a.out 2147483647 2147483647
Illegal instruction (core dumped)
$ icc -O2 t.c
$ ./a.out 2147483647 2147483647
2147483647 2147483647 -2147483648
There's no difference whether we add -fno-strict-overflow or not.
---
fs/exec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/exec.c b/fs/exec.c
index 18c45ca..20df02c 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -434,8 +434,9 @@ static int count(struct user_arg_ptr argv, int max)
if (IS_ERR(p))
return -EFAULT;
- if (i++ >= max)
+ if (i >= max)
return -E2BIG;
+ ++i;
if (fatal_signal_pending(current))
return -ERESTARTNOHAND;
--
1.7.10.4
next reply other threads:[~2013-01-06 5:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-06 5:29 Xi Wang [this message]
2013-01-07 21:44 ` [PATCH RFC] exec: avoid possible undefined behavior in count() Andrew Morton
2013-01-16 21:47 ` Xi Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1357450145-23964-1-git-send-email-xi.wang@gmail.com \
--to=xi.wang@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.