[llvm-bugs] [Bug 44597] New: Undefined behavior in undefined behavior santizer for shifts

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Jan 20 07:33:04 PST 2020


https://bugs.llvm.org/show_bug.cgi?id=44597

            Bug ID: 44597
           Summary: Undefined behavior in undefined behavior santizer for
                    shifts
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ubsan
          Assignee: unassignedbugs at nondot.org
          Reporter: cullmann at absint.de
                CC: llvm-bugs at lists.llvm.org

Hi,

we did some experiments with the shift sanitizer.

For the following code:

int main() {
  signed char c = -2;

  c = c << 4; // Okay integer promotion, sanitizer datastructure says 32-bit
wide operand

  c = -2;

  c <<= 4; // Integer promotion is done, but sanitizer datastructure says 8-bit
wide operand
  // Consequence -> This eventually causes undefined behaviour in
getSIntValue() [Sanitizer Handler Library] since shifting a negative 32-bit
value by (128-8) bits to the left.

  return 0;
}

the second call to the shift sanitizer routine will get a sext32 extended value
but has a getIntegerBitWidth of 8 internally in its data structures.

That will lead to "shift overflow" for the signed shift in:

SIntMax Value::getSIntValue() const {
  CHECK(getType().isSignedIntegerTy());
  if (isInlineInt()) {
    // Val was zero-extended to ValueHandle. Sign-extend from original width
    // to SIntMax.
    const unsigned ExtraBits =
      sizeof(SIntMax) * 8 - getType().getIntegerBitWidth();
    return SIntMax(Val) << ExtraBits >> ExtraBits;
  }

I would propose to change this

return SIntMax(Val) << ExtraBits >> ExtraBits;

to

return SIntMax(UIntMax(Val) << ExtraBits) >> ExtraBits;

to avoid the undefined left shift on a signed value that shifts some bits out.

Or are we confused here?

-- 
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/20200120/bb8452c4/attachment.html>


More information about the llvm-bugs mailing list