Dynamically linked binaries aren't linked by kernel, but by "elf interpreter" specified by one of the elf header fields. This points to another binary which is executed in, iirc, slightly different way, with the intended binary file passed as well.
The elf interpreter is then responsible for loading the file into memory, handling all the shared library linking or other special operations, and then jumps to actual programs start point as specified by elf header. Generally it does it by parsing the elf headers, resolving all the symbols recursively, and calling mmap() to properly allocate memory for the program as well as to mmap() the program text and libraries into memory.
So there are two loaders involved even if kernel had only one, because the kernel loader is simplified and doesn't handle full scope of ELF nor is it supposed to handle dynamic linking.
Without looking at the code in question, I'd guess it's junk from the loader binary; mmaping the file into the range, but not filling the end properly seems like a much easier mistake than having a one off amd broken way to get disk content and a little extra into memory for loading loaders.
That's not what I read from this at all? My takeaway is that Linux has different ELF loading code for normal executables and for the dynamic linker (ld.so), the one for ld.so is buggy, and LLVM's linker (lld) produces binaries which trigger the bug, so an ld.so produced by lld won't work.
Reporting bugs to the kernel bugzilla has high chance of being pointless. Most developers never use it. Needs to be posted to the mailing list (hardest part is locating the correct list).
I remember it wasn't that bad before - not into kernel things anymore but I guess posting a slightly flashy bug report on the main LKML (linux-kernel@vger.kernel.org) should get some attention.
I think those people doing alternative libc, compilers, etc. are also doing a great secondary job at dusting some very stable corners of Linux. And a third very big value is all those blog posts they generate to educate all of us lay people on some details of the system.
17 comments
[ 5.2 ms ] story [ 48.4 ms ] threadI thought dynamically linked binaries are still ELF, but have special code to load shared object files into the right places in memory.
The elf interpreter is then responsible for loading the file into memory, handling all the shared library linking or other special operations, and then jumps to actual programs start point as specified by elf header. Generally it does it by parsing the elf headers, resolving all the symbols recursively, and calling mmap() to properly allocate memory for the program as well as to mmap() the program text and libraries into memory.
So there are two loaders involved even if kernel had only one, because the kernel loader is simplified and doesn't handle full scope of ELF nor is it supposed to handle dynamic linking.
Is this heartbleed for ELF, or is the junk always mapped from the ELF binary itself (or the ldd binary, whose content is ostensibly common knowledge)?
Coming from a Rust enjoyer. Don't use it myself but see the benefits. But those oneliners always make me chuckle.
So there is random unzeroed junk at the end of BSS, which only bites us with release optimizations. Sounds security to me