Red Hat Bugzilla – Bug 160199
CVE-2005-1768 64bit execve() race leads to buffer overflow
Last modified: 2007-11-30 17:07:07 EST
Reported to firstname.lastname@example.org by Ilja van Sprundel, a race condition in execve
affecting x86_64 and ia64 which exists because kmalloc() or get_user() can
block, and hence another thread can change the argv and envp pointers, causing a
bufferoverflow (also on SMP without blocking)
na = nargs(argv, NULL);
... ne = nargs(envp, NULL);
... len = (na + ne + 2) * sizeof(*av);
... av = kmalloc(len, GFP_KERNEL);
... r = nargs(argv, av);
... r = nargs(envp, ae);
"the nargs() function is used to first count the amount of argv and
envp pointers, next a kmalloc() is done, and then nargs() is called again to
copy the argv and envp pointer into this newly allocated memory. the race
condition exists because kmalloc() or get_user() can block, and hence another
thread can change the argv and envp pointers, causing a buffer overflow."
Created attachment 115347 [details]
Proposed patch from Andi Kleen
The patch posted in Comment #1 is clearly "theoretical" because it
wouldn't work or apply. Ernie's reference to the need for a "signed int" is
one example, and in addition, the ia64 piece shows a "cnt" variable
below which doesn't exist (it should be "n"):
+ if (n >= (MAX_ARG_PAGES * PAGE_SIZE) / sizeof(char *) || (max >= 0 && cnt >=
In any case, with a patch cobbled into place, and run against a test program
Ernie whipped up, there's what appears to be a regression, where the test
program works OK without the patch, but fails with it -- returning E2BIG when
it shouldn't. So further investigation to determine whether patch was created
incorrectly is in order.
So if Andi Kleen posts a public patch today, can you copy it to this bugzilla
ASAP for comparison to the old one?
Created attachment 116130 [details]
Update/fix of Andi Kleen's proposed patch
The attached patch addresses the two irregularities in Andi Kleen's patch
mentioned above (the "unsigned int" and the "cnt" complaints), as well as
two other fixes:
(1) ensure that the correct errno gets passed back in the x86_64 case, and
(2) fixes for both the x86_64 and ia64 nargs() "if" statements that cause E2BIG
to be returned.
We would like to compare this patch to the upstream version that get applied.
Created attachment 116183 [details]
Second proposed patch from Andi Kleen
Created attachment 116184 [details]
Update/fix of Andi Kleen's second proposed patch
Andi Kleen sent us an updated version of his original patch,
which he said was sent to Marcelo. However, it has two bugs
in it, which I have fixed in the attached patch.
I sent Andi the following response regarding the bugs:
There appears to be two problems with this patch:
(1) In the x86_64 case, if the user attempts to use too
many arguments, the intial call to nargs() will recognize
it, and return E2BIG. But then sys32_execve() ignores
the E2BIG return argument and returns EFAULT. The ia64
case works OK because it returns what nargs() returns.
(2) Also in the x86_64 case, nargs() returns the number of
arguments found, which sys32_execve() stores in "na", and
which is later passed back to nargs() as the "max" arg.
But the second call to nargs() will then allow "na+1"
arguments, and therefore the buffer overflow. So the
second set of calls to nargs() should pass "na-1" and
"ne-1" respectively. The ia64 case works OK because its
nargs() returns the number of arguments minus 1.
I verified case (1). As far as (2), I've never been able to
reproduce the the overflow, but the logic seems to make sense.
Public 20050704, opening embargo
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-32.10.EL).
Is there a reproducer for this bug that QE can use for testing this ?
Actually, no. I don't believe anybody has ever reproduced it.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.