Red Hat Bugzilla – Bug 231442
kernel fails to add AT_NULL terminator to auxiliary vector
Last modified: 2008-08-15 19:00:22 EDT
Description of problem:
It is possible for ELF binaries to be launched by the kernel
without a terminating AT_NULL in the auxilliary vector. This
will confuse the dynamic linker and potentially cause it to crash.
Reason for failure is because the saved_auxv vector in the mm_struct
is not large enough to fit all possible entries. This can occur for
64-bit ELF binaries that also have a AT_EXECFD entry, bearing in mind
that 64-bit binaries often have a number of additional AT_IGNORE entries.
Version-Release number of selected component (if applicable):
Very reproducible. Without a AT_NULL terminator the linker just
parses random memory until it runs off the stack.
Steps to Reproduce:
1. Register a 64-bit handler in binfmt_misc with the flags POC for
any arbitrary binary format of type P.
2. Invoke the handler by executing a binary file of type P.
3. If this doesn't happen readily, then try setting certain
environment variables such as LD_SHOW_AUXV=1 or LD_DEBUG=all, etc.
Certain specially invoked 64-bit ELF binaries can crash in the linker.
The linker never crashes.
Here are the 22 entries found in a 64-bit ELF binary that
causes the linker to crash:
The saved_auxv member only has space for 22 entries, thus it
cannot fit an extra AT_NULL.
----- Additional Comments From firstname.lastname@example.org (prefers email at email@example.com) 2007-08-08 10:04 EDT -------
Hrm, that's becoming a recurring problem. We bumpted the size to 44 (22 entries
without NULL terminator) in 2.6.16 because of that. It seems to be that
something (either RHEL5 or upstream, I would have to check) added some new
entries without bumping the size of the array. I suspect we may want to change
the logic here to avoid the problem once for all.
I'm away and travelling for about a month so I won't be able to do anything
there but that's definitely something that needs to be looked at more closely
and fixed, maybe Paul can have a go ? The fix for now is trivial, just bump the
array size to 46 instead of 44 (AT_VECTOR_SIZE in include/linux/auxvec.h), but
we should look into doing something better to avoid the problem in the future
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
You can download this test kernel from http://people.redhat.com/dzickus/el5
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.
------- Comment From firstname.lastname@example.org 2008-06-26 05:22 EDT-------
Is the fix for this bug expected to be in the next update/release?
Well, it's not "unused". It's necessary to be backward compatible with old old
old glibc's. I suppose that's not a big deal to lose that compatibility in RHEL
tough as the affected glibc is really very old.