From: Dmitry Vyukov <dvyukov@google.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: syzbot <syzbot+e4c1dd36fc6b98c50859@syzkaller.appspotmail.com>,
David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
Steffen Klassert <steffen.klassert@secunet.com>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: [syzbot] UBSAN: shift-out-of-bounds in xfrm_selector_match
Date: Tue, 15 Jun 2021 07:51:25 +0200 [thread overview]
Message-ID: <CACT4Y+YZVgJiRkQdmw-Oc407u9xg2nzeYstv0QVe40xrDimtUQ@mail.gmail.com> (raw)
In-Reply-To: <20210615053159.GA5412@gondor.apana.org.au>
On Tue, Jun 15, 2021 at 7:32 AM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Jun 10, 2021 at 12:19:26PM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 13c62f53 net/sched: act_ct: handle DNAT tuple collision
> > git tree: net
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16635470300000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=770708ea7cfd4916
> > dashboard link: https://syzkaller.appspot.com/bug?extid=e4c1dd36fc6b98c50859
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+e4c1dd36fc6b98c50859@syzkaller.appspotmail.com
> >
> > UBSAN: shift-out-of-bounds in ./include/net/xfrm.h:838:23
> > shift exponent -64 is negative
> > CPU: 0 PID: 12625 Comm: syz-executor.1 Not tainted 5.13.0-rc3-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:79 [inline]
> > dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> > ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
> > __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327
> > addr4_match include/net/xfrm.h:838 [inline]
> > __xfrm4_selector_match net/xfrm/xfrm_policy.c:201 [inline]
> > xfrm_selector_match.cold+0x35/0x3a net/xfrm/xfrm_policy.c:227
> > xfrm_state_look_at+0x16d/0x440 net/xfrm/xfrm_state.c:1022
>
> This appears to be an xfrm_state object with an IPv4 selector
> that somehow has a prefixlen (d or s) of 96.
>
> AFAICS this is not possible through xfrm_user. OTOH it is not
> obvious that af_key is entirely consistent in how it verifies
> the prefix length, in particular, it seems to be possible for
> two addresses with conflicting families to be provided as src/dst.
>
> Can you confirm that this is indeed using af_key (a quick read
> of the syzbot log seems to indicate that this is the case)?
Hi Herbert,
This was triggered by this program and, yes, it creates an AF_KEY socket:
18:01:48 executing program 1:
r0 = socket$inet_udp(0x2, 0x2, 0x0)
socket$key(0xf, 0x3, 0x2)
bind$inet(r0, &(0x7f00000001c0)={0x2, 0x0, @local}, 0x10)
socketpair$tipc(0x1e, 0x5, 0x0, &(0x7f00000000c0)={0xffffffffffffffff,
<r1=>0xffffffffffffffff})
ioctl$TUNSETLINK(r1, 0x8912, 0x400308)
connect$inet(r0, &(0x7f0000000480)={0x2, 0x0, @multicast2}, 0x10)
setsockopt$inet_IP_XFRM_POLICY(r0, 0x0, 0x11,
&(0x7f0000000080)={{{@in6=@ipv4={'\x00', '\xff\xff', @dev},
@in6=@private0, 0x0, 0xfffc, 0x0, 0x0, 0x2, 0x0, 0x0, 0x0, 0x0,
0xee01}, {0x2}, {}, 0x0, 0x0, 0x1}, {{@in, 0x0, 0x32}, 0x0,
@in6=@loopback, 0x0, 0x0, 0x0, 0xb7}}, 0xe8)
socket$key(0xf, 0x3, 0x2)
sendmmsg(r0, &(0x7f0000007fc0), 0x800001d, 0x0)
prev parent reply other threads:[~2021-06-15 5:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 19:19 [syzbot] UBSAN: shift-out-of-bounds in xfrm_selector_match syzbot
2021-06-15 5:31 ` Herbert Xu
2021-06-15 5:51 ` Dmitry Vyukov [this message]
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=CACT4Y+YZVgJiRkQdmw-Oc407u9xg2nzeYstv0QVe40xrDimtUQ@mail.gmail.com \
--to=dvyukov@google.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=syzbot+e4c1dd36fc6b98c50859@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.