On Mon, Dec 21, 2020 at 12:23 PM Jason A. Donenfeld <[email protected]> wrote: > > Hi Dmitry, > > On Mon, Dec 21, 2020 at 10:14 AM Dmitry Vyukov <[email protected]> wrote: > > Hi Jason, > > > > Thanks for looking into this. > > > > Reading clang docs for ubsan: > > > > https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html > > -fsanitize=object-size: An attempt to potentially use bytes which the > > optimizer can determine are not part of the object being accessed. > > This will also detect some types of undefined behavior that may not > > directly access memory, but are provably incorrect given the size of > > the objects involved, such as invalid downcasts and calling methods on > > invalid pointers. These checks are made in terms of > > __builtin_object_size, and consequently may be able to detect more > > problems at higher optimization levels. > > > > From skimming though your description this seems to fall into > > "provably incorrect given the size of the objects involved". > > I guess it's one of these cases which trigger undefined behavior and > > compiler can e.g. remove all of this code assuming it will be never > > called at runtime and any branches leading to it will always branch in > > other directions, or something. > > Right that sort of makes sense, and I can imagine that in more general > cases the struct casting could lead to UB. But what has me scratching > my head is that syzbot couldn't reproduce. The cast happens every > time. What about that one time was special? Did the address happen to > fall on the border of a mapping? Is UBSAN non-deterministic as an > optimization? Or is there actually some mysterious UaF happening with > my usage of skbs that I shouldn't overlook?
These UBSAN checks were just enabled recently. It's indeed super easy to trigger: 133083 VMs were crashed on this already: https://syzkaller.appspot.com/bug?extid=8f90d005ab2d22342b6d So it's one of the top crashers by now.
