http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section The gABI clearly states "In 64-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS64), each entry is an array of 8-byte words in the format of the target processor. In 32-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS32), each entry is an array of 4-byte words in the format of the target processor." However, csu/abi-note.S incorrectly documents and implements the note fields as 4-byte integers. Any ABI-compliant ELF processor will therefore get invalid values when processing such note sections. There are a number of ways this can be fixed, some of which will take co-operation from the link editor (I will file a bug about this in binutils) and some of which is in glibc. First, on 64-bit systems the .note section should *ALWAYS* be aligned on an 8-byte boundary because it is supposed to contain 8-byte values. So if the link editor correctly sets this alignment it will be a clue that the .note section is possibly correct. Secondly, the code in elf/dl-load.c should be trained to correctly detect whether such an existing .note section used 4-byte words or 8-byte words, again using the segment alignment as a clue (but not relying on it).
This is a known issue: https://github.com/hjl-tools/linux-abi/commit/9a7bc47bf065405c2e7b6c46d692a7d137d5f544 See: https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf
Note that the linked WSL issue is likely not caused by ABI alignment, but by the contents of the ELF note (which we do not know) in relation to data provided by the WSL environment.