[Bug c/78408] New: Aggressive optimization of zeroing results in incorrect behavior

npmccallum at redhat dot com gcc-bugzilla@gcc.gnu.org
Thu Nov 17 18:53:00 GMT 2016


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

            Bug ID: 78408
           Summary: Aggressive optimization of zeroing results in
                    incorrect behavior
           Product: gcc
           Version: 6.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: npmccallum at redhat dot com
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC)

Compiling the file uses this command line:

gcc -DPACKAGE_NAME=\"clevis\" -DPACKAGE_TARNAME=\"clevis\"
-DPACKAGE_VERSION=\"1\" -DPACKAGE_STRING=\"clevis\ 1\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE_URL=\"\" -DPACKAGE=\"clevis\" -DVERSION=\"1\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -I.    -Wall -Wextra -Werror -Wstrict-aliasing
-Wchar-subscripts -Wformat-security -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wshadow -Wsign-compare -Wstrict-prototypes
-Wtype-limits -Wno-missing-field-initializers -Wno-unused-parameter  -pthread
-I/usr/include/udisks2 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-DCLEVIS_CMD_DIR=/usr/libexec/clevis -g -O2 -MT clevis-luks-udisks2.o -MD -MP
-MF $depbase.Tpo -c -o clevis-luks-udisks2.o clevis-luks-udisks2.c

The relevant code is here[1].

GCC sees that "pkt_t key" might go out of scope and therefore optimizes out the
zeroing of the struct that occurs at the end of the for loop iteration.
However, key doesn't go out of scope during loop iteration. Thus, on subsequent
loops the struct is used presuming that it contains a zero value but it
doesn't. This means that (what I take to be) perfectly valid ISO C behaves in
strange ways.

In particular, the bug that arises is as follows. When load_jwe() fails[2], the
(incorrectly) presumed zeroed key struct is sent[3] to the client. The end
result is that an invalid key (the previous successful one) is sent when an
empty UDP packet should be sent.

GCC should detect that "pkt_t key" is not going out of scope and should zero it
as requested rather than invalidly optimizing out this statement. Clang does
not have this bug, so there is at least one example of a compiler doing the
right thing.

[1] -
https://github.com/latchset/clevis/blob/6834b02b390771a97775dcfa26f85243f3a0195d/udisks2/clevis-luks-udisks2.c#L446
[2] -
https://github.com/latchset/clevis/blob/6834b02b390771a97775dcfa26f85243f3a0195d/udisks2/clevis-luks-udisks2.c#L455
[3] -
https://github.com/latchset/clevis/blob/6834b02b390771a97775dcfa26f85243f3a0195d/udisks2/clevis-luks-udisks2.c#L469


More information about the Gcc-bugs mailing list