Description of problem: ELF program with one segment (PT_LOAD) that is read-only gets SIGKILL from load_elf_binary() in fs/binfmt_elf.c. This is because the kernel tries to zero the page fragment at the high end of the PT_LOAD (that would be .bss) but clear_user returns failure because there is no Write permission. load_elf_binary() notices the failure, and kills the process. The following kernels are affected 2.6.11-1.14_FC3 2.6.12-1.1381_FC3 2.6.12-2.3.legacy_FC3 kernel-2.6.16-1.2115_FC4 The following kernels are ok 2.6.10-1.741_FC3 2.6.10-1.770_FC3 How reproducible: Programs compressed with "upx-2.01 --force-execve" are in this case Here is a simple test case: $ cat one_ptload.S #include <asm/unistd.h> _start: .globl _start movl $0,%ebx # success movl $ __NR_exit,%eax int $0x80 $ cat one_ptload.lds OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") OUTPUT_ARCH(i386) PHDRS { phdr0 PT_LOAD FILEHDR PHDRS FLAGS(5); } SECTIONS { . = 0x08048000 + SIZEOF_HEADERS; . = ALIGN(0x80); .data : { *(.text) *(.rodata) *(.data) *(.bss) *(COMMON) } : phdr0 } $ gcc -nostartfiles -nostdlib -Wl,-T,one_ptload.lds one_ptload.S $ readelf --segments a.out Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x08048000 0x08048000 0x0008c 0x0008c R E 0x1000 $ ./a.out Segmentation fault $ strace ./a.out execve("./a.out", ["./a.out"], [/* 40 vars */]) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ ## Now try the same program with two PT_LOADs: $ gcc -nostartfiles -nostdlib one_ptload.lds $ readelf --segments a.out Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x08048000 0x08048000 0x00080 0x00080 R E 0x1000 LOAD 0x000080 0x08049080 0x08049080 0x00000 0x00000 RW 0x1000 $ ./a.out $ # Note no Segfault Thanks to John Reiser for providing the test case
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
This bug affects FC3 and FC4 kernel (see previous listing), I don't know for FC5.
You may get faster resolution on this bug by reporting this upstream to linux-kernel.org, or filing a bug in http://bugzilla.kernel.org I just double-checked that this bug is reproducable on a vanilla kernel, so this isn't a Fedora specific issue. Thanks.
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
(this is a mass-close to kernel bugs in NEEDINFO state) As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. If you believe that this bug was closed in error, please feel free to reopen this bug.