[llvm-bugs] [Bug 48726] New: UBSAN: split object-size into real accesses and casts

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Jan 12 01:53:38 PST 2021


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

            Bug ID: 48726
           Summary: UBSAN: split object-size into real accesses and casts
           Product: compiler-rt
           Version: 11.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ubsan
          Assignee: unassignedbugs at nondot.org
          Reporter: dvyukov at google.com
                CC: llvm-bugs at lists.llvm.org

This come up while testing the Linux kernel:
https://groups.google.com/g/syzkaller-bugs/c/b_y3xw0wvOI/m/L074F0v3BQAJ

A minimal repro is:

#include <stdio.h>
#include <stdlib.h>

struct X {
        unsigned x;
};

struct Y {
        unsigned x;
        unsigned y;
};

void foo(struct Y* y, unsigned x)
{
        y->x += x;
}

void bar(struct X* x)
{
        if (x->x % 3)
                printf("%d\n", x->x);
}

int main() {
        struct X x;
        x.x = 0;
        foo((struct Y*)&x, rand());
        foo((struct Y*)&x, rand());
        bar(&x);
        return 0;
}

$ clang -v
clang version 11.0.0 (https://github.com/llvm/llvm-project.git
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
$ clang test.c -fsanitize=undefined -O2 -g
$ ./a.out 

test.c:15:5: runtime error: member access within address 0x7ffc3ebe41e0 with
insufficient space for an object of type 'struct Y'

Here X and Y has the same "prefix" and we don't _access_ data outside of the
allocated object, but we cast smaller object to larger object. I assume this is
still undefined behavior, but how feasible is it to split this check into
actually accessing non-allocated memory and doing casts/calling functions with
wrong types? Does it make sense? This would help with incremental deployment.

-- 
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/20210112/90369859/attachment.html>


More information about the llvm-bugs mailing list