Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Kees Cook <keescook@google.com>, Netdev <netdev@vger.kernel.org>,
	 syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	 WireGuard mailing list <wireguard@lists.zx2c4.com>,
	Eric Dumazet <edumazet@google.com>
Subject: Re: UBSAN: object-size-mismatch in wg_xmit
Date: Mon, 21 Dec 2020 12:23:04 +0100	[thread overview]
Message-ID: <CAHmME9q0HMz+nERjoT-TQ8_6bcAFUNVHDEeXQAennUrrifKESw@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+ac8oFk1Sink0a6VLUiCENTOXgzqmkuHgQLcS2HhJeq=g@mail.gmail.com>

Hi Dmitry,

On Mon, Dec 21, 2020 at 10:14 AM Dmitry Vyukov <dvyukov@google.com> 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?

Jason

  reply	other threads:[~2020-12-21 11:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-20 16:54 syzbot
2020-12-20 21:11 ` Jason A. Donenfeld
2020-12-21  9:14   ` Dmitry Vyukov
2020-12-21 11:23     ` Jason A. Donenfeld [this message]
2021-01-07 12:22       ` Dmitry Vyukov
2021-01-07 19:00         ` Jason A. Donenfeld
2021-01-07 19:06           ` Jeffrey Walton
2021-01-08  0:34             ` Corey Costello
2021-01-08  0:42               ` Eric Light
2021-01-08  0:44                 ` Corey Costello
2021-01-08  0:50                   ` Eric Light
2021-01-08  1:02                 ` Phillip McMahon
2021-01-08  9:33             ` Dmitry Vyukov
2021-01-08 20:54               ` Nathan Chancellor
2021-01-08  9:30           ` Dmitry Vyukov
     [not found]             ` <CAGXu5j+jzmkiU_AWoTVF6e263iYSSJYUHB=Kdqh-MCfEO-aNSg@mail.gmail.com>
2021-01-09  9:46               ` Dmitry Vyukov
2021-01-09 10:49                 ` Matthias Urlichs
2021-01-11 17:17                 ` Dmitry Vyukov
2021-01-11 17:35                   ` Jeffrey Walton
2021-01-11 17:58                     ` Dmitry Vyukov
2021-01-11 18:14                       ` Jeffrey Walton
2021-01-12  9:54                         ` Dmitry Vyukov
2021-01-07 12:53       ` Jeffrey Walton
2021-01-07 17:01       ` Julian Wiedmann
2021-01-07 18:58         ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHmME9q0HMz+nERjoT-TQ8_6bcAFUNVHDEeXQAennUrrifKESw@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=keescook@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).