What U. Drepper noticed is that there is a padding of 4 additional bytes in 64-bit processors that can result to a 4 byte information leak from the kernel. Specifically, the padding is between ‘ss_flags’ and ‘ss_size’ since void * has size of 8 bytes in 64-bit architectures, and size_t which can be found at arch/x86/include/asm/posix_types_64.h is of unsigned long type, meaning 8 bytes as well. However, int type will remain 4 bytes long. In order to have alignment between the 4 bytes long ‘ss_flags’ variable and ‘ss_size’, 4 additional bytes are added as padding. Of course, since this structure is directly (not initialized first) used and then copied to userspace using copy_to_user(), 4 padding bytes will be uninitialized and result in an information disclosure vulnerability when copied to the userspace. To fix this, U. Drepper changed the first if clause so that the structure is initialized regardless of the ‘uoss’ user controlled pointer like this:

Now, it performs a range check using access_ok() macro and then copies the three members of stack_t structure one at a time using __put_user(). If any of these fail, it exits with the equivalent error code. This issue has been fixed in 2.6.31-rc5-git1 and an exploit code has already been published by Jon Oberheide.