[llvm-bugs] [Bug 32842] New: MemorySanitizer false negatives on comparisons

[via llvm-bugs]

http://bugs.llvm.org/show_bug.cgi?id=32842

            Bug ID: 32842
           Summary: MemorySanitizer false negatives on comparisons
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: glider at google.com
                CC: dvyukov at google.com, eugeni.stepanov at gmail.com,
                    kcc at google.com, llvm-bugs at lists.llvm.org

Created attachment 18378
  --> http://bugs.llvm.org/attachment.cgi?id=18378&action=edit
Reproducer

For the attached program MSan generates code that produces a false negative
when comparing two integers.

Consider iphdr is declared as:

  5 struct iphdr {
  6   u8 ihl:4, version: 4;
  ..
 12 };

And in the following code iph->ihl is uninitialized (see ub.c for full code):

 15 int raw_send_hdrinc(unsigned long int length) {
 16   struct iphdr *iph;
 17   unsigned int iphlen;
 18   int err = 0;
 19   iph = get_iphdr();
 20   iphlen = iph->ihl * 4;
 21   printf("&iphlen: %p\n", &iphlen);
 22   err = -1;
 23   if (iphlen > length) {
 24     printf("error!\n");
 25     goto error_free;
 26   }

Looking at the IR built with the default flags I see the following
chunk corresponding to the comparison:

 90   %27 = load i32, i32* %iphlen, align 4, !tbaa !2
 91   %_msld6 = load i32, i32* %21, align 4
 92   %_msprop7 = zext i32 %_msld6 to i64
 93   %conv2 = zext i32 %27 to i64
 94   %_msprop8 = or i64 %1, %_msprop7
 95   %28 = and i64 %_msprop8, 1
 96   %29 = icmp eq i64 %28, 0
 97   %cmp = icmp ugt i64 %conv2, %length
 98   br i1 %29, label %34, label %30, !prof !1

Here %1 is the shadow for |length| and %_msld6 is the shadow for |iphlen|.
In the case |length| is fully initialized, the lowest bit of %_msprop8 is zero
(because the two lowest bits of iphlen are initialized).
Then despite the result of comparison is uninitialized and  %_msprop8 is
non-zero, it's truncated to a zero bit, so the uninitializedness is lost.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170428/aafdd240/attachment-0001.html>