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): How reproducible: 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. Actual results: Certain specially invoked 64-bit ELF binaries can crash in the linker. Expected results: The linker never crashes. Additional info: Here are the 22 entries found in a 64-bit ELF binary that causes the linker to crash: AT_IGNORE AT_IGNORE AT_DCACHEBSIZE AT_ICACHEBSIZE AT_UCACHEBSIZE AT_SYSINFO_EHDR AT_HWCAP AT_PAGESZ AT_CLKTCK AT_PHDR AT_PHENT AT_PHNUM AT_BASE AT_FLAGS AT_ENTRY AT_UID AT_EUID AT_GID AT_EGID AT_SECURE AT_PLATFORM AT_EXECFD The saved_auxv member only has space for 22 entries, thus it cannot fit an extra AT_NULL.
----- Additional Comments From bherren.com (prefers email at benh.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 for upstream.
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 release.
in 2.6.18-60.el5 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. http://rhn.redhat.com/errata/RHBA-2008-0314.html
------- Comment From vinaysridhar.com 2008-06-26 05:22 EDT------- RedHat, 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.