Summary: | sys-libs/glibc : Segmentation fault in ld.so on invalid ELF files | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Bezrukov <phmagic> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | kernel |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Example of shared object which causes crash |
Description
Alexander Bezrukov
2017-11-10 23:58:16 UTC
I realized what made this vdso64.so from linux kernel "toxic". It is CONFIG_LEGACY_VSYSCALL_EMULATE=y on the "bad" host. On the "good" host the selection is CONFIG_LEGACY_VSYSCALL_NONE=y (Both settings are on purpose.) This also probably explains why memory becomes read-write after the fault. Anyway, in my opinion, ld.so should not segfault with any input. Yep, that looks like a bug. (In reply to Alexander Bezrukov from comment #1) > I realized what made this vdso64.so from linux kernel "toxic". It is > > CONFIG_LEGACY_VSYSCALL_EMULATE=y > > on the "bad" host. On the "good" host the selection is > > CONFIG_LEGACY_VSYSCALL_NONE=y > > (Both settings are on purpose.) > > This also probably explains why memory becomes read-write after the fault. > > Anyway, in my opinion, ld.so should not segfault with any input. I suggest reporting the bug directly upstream. I would be very wary to add gentoo-specific code in early startup phase. It's very easy to break. ld.so does minimal to no validation of mapped ELF files: libc is not loaded, relocations are not yet processed. It's a very sensitive piece of code both from performance and fragility standpoints. But maybe it can be tweaked for this particular case. https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=1220183ce29f83668d2044dc25093c08184335fe;hb=HEAD#l857 Note how little it does before actually crashing: $ LD_DEBUG=all /lib/ld-2.26.so --list ./vdso64.so 24623: file=./vdso64.so [0]; generating link map <SIGSEGV> $ strace -f /lib/ld-2.26.so --list ./vdso64.so execve("/lib/ld-2.26.so", ["/lib/ld-2.26.so", "--list", "./vdso64.so"], 0x7ffe60180838 /* 80 vars */) = 0 brk(NULL) = 0x7fa529126000 openat(AT_FDCWD, "./vdso64.so", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\t\0\0\0\0\0\0"..., 832) = 832 lseek(3, 1960, SEEK_SET) = 1960 read(3, "\6\0\0\0\4\0\0\0\0\0\0\0Linux\0\0\0<\t\4\0\4\0\0\0\24\0\0\0"..., 60) = 60 fstat(3, {st_mode=S_IFREG|0755, st_size=4512, ...}) = 0 getcwd("/home/slyfox/Downloads", 128) = 23 mmap(NULL, 3209, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa5277bc000 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7fa5277bc370} --- +++ killed by SIGSEGV (core dumped) +++ From comment #3 I assume that this is not restricted to 2.25 ... When you file an upstream bug report, please link to it here! If you are still interested in making ld.so more robust please file upstream bug report at: https://sourceware.org/bugzilla/enter_bug.cgi?product=glibc Gentoo will not add extra downstream validation to the loader. |