So today musl discovered a longstanding bug in Linux's ELF loader

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.

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).

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.