From: Sabrina Dubroca <sd@queasysnail.net>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: pabeni@redhat.com,
syzbot <syzbot+cc39f136925517aed571@syzkaller.appspotmail.com>,
davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au, kuba@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [net?] UBSAN: shift-out-of-bounds in xfrm_selector_match (2)
Date: Tue, 1 Oct 2024 19:10:19 +0200 [thread overview]
Message-ID: <Zvws-45NVXIMUYl4@hog> (raw)
In-Reply-To: <ZvZu9TmFs5VFhjLw@hog>
Hi Steffen,
2024-09-27, 10:38:13 +0200, Sabrina Dubroca wrote:
> 2024-09-27, 09:30:09 +0200, Steffen Klassert wrote:
> > On Wed, Sep 25, 2024 at 01:08:48PM +0200, Sabrina Dubroca wrote:
> > > Maybe a check for prefixlen < 128 would also be useful in the
> > > XFRM_STATE_AF_UNSPEC case, to avoid the same problems with syzbot
> > > passing prefixlen=200 for an ipv6 SA. I don't know how
> > > XFRM_STATE_AF_UNSPEC is used, so I'm not sure what restrictions we can
> > > put. If we end up with prefixlen = 100 used from ipv4 we'll still have
> > > the same issues.
> >
> > I've introduced XFRM_STATE_AF_UNSPEC back in 2008 to make
> > inter addressfamily tunnels working while maintaining
> > backwards compatibility to openswan that did not set
> > the selector family. At least that's what I found in
> > an E-Mail conversation from back then.
> >
> > A check for prefixlen <= 128 would make sense in any case.
> > But not sure if we can restrict that somehow further.
>
> I'll add this check too, and then I'll run some more experiments with
> that flag.
I ended up not adding the check, since for x->sel.family == AF_UNSPEC,
xfrm_state_look_at doesn't use the selector at all, so I don't think
restricting prefixlen in that case would do anything.
--
Sabrina
prev parent reply other threads:[~2024-10-01 17:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-16 22:47 [syzbot] [net?] UBSAN: shift-out-of-bounds in xfrm_selector_match (2) syzbot
2024-09-24 21:51 ` syzbot
2024-09-25 11:08 ` Sabrina Dubroca
2024-09-27 7:30 ` Steffen Klassert
2024-09-27 8:38 ` Sabrina Dubroca
2024-10-01 17:10 ` Sabrina Dubroca [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=Zvws-45NVXIMUYl4@hog \
--to=sd@queasysnail.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.com \
--cc=syzbot+cc39f136925517aed571@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.