[Bug driver/77992] New: Failures to initialize padding bytes -- causing many information leaks

["kjlu at gatech dot edu" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992

            Bug ID: 77992
           Summary: Failures to initialize padding bytes -- causing many
                    information leaks
           Product: gcc
           Version: 5.4.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kjlu at gatech dot edu
  Target Milestone: ---

Created attachment 39817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39817&action=edit
testcase

Hello,

I'd like to report an implementation (or even design) problem in GCC.

Chapter §6.7.9/10 in C11:
"If an object that has static or thread storage duration is not initialized
explicitly, then:
...
if it is an aggregate, every member is initialized (recursively) according to
these rules, and any padding is initialized to zero bits;"

According to this specification, padding bytes should be initialized when the
initializer is static.
Take a look at this example (say x86_64):
/////////////////////////////
struct S {
        long l;
        char c;
};

void main () {
        struct S s ={
                .l = 0,
                .c = 0
        };
}
/////////////////////////////
The developer has carefully initialized all fields with constants.
Object "s" is supposed to be fully initialized, i.e., the seven padding bytes
right after "s.c" are supposed to be initialized.
However, these padding bytes are not initialized in fact. 
In contrast, LLVM would initialize the padding bytes in such a case.

Similarly, when "variables" are used to initialize the fields of "s", padding
bytes are not initialized either, such as:
/////////////////////////////
        struct S s ={
                .l = variable1,
                .c = variable2
        };
/////////////////////////////

Such failures to initialize padding bytes will result in many information
leaks. We have found many information leaks in the Linux kernel.
Here is an example:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4482
More information can be found in our research paper:
http://www.cc.gatech.edu/~klu38/publications/unisan-ccs16.pdf

The testing program for reproducing the leak is attached.

Testing environment:
"Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)"


My suggestion to reliably address this problem is that padding bytes of an
object, which are implicitly introduced by compilers, should be
zero-initialized upon object allocation.

Please let me know if you need more information or any assistance.

Best Regards,
Kangjie Lu