From: Steffen Klassert <steffen.klassert@secunet.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: syzbot <syzbot+577fbac3145a6eb2e7a5@syzkaller.appspotmail.com>,
<davem@davemloft.net>, <kuba@kernel.org>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
<syzkaller-bugs@googlegroups.com>
Subject: Re: KASAN: stack-out-of-bounds Read in xfrm_selector_match (2)
Date: Thu, 24 Sep 2020 10:02:05 +0200 [thread overview]
Message-ID: <20200924080205.GD20687@gauss3.secunet.de> (raw)
In-Reply-To: <20200924074351.GB9879@gondor.apana.org.au>
On Thu, Sep 24, 2020 at 05:43:51PM +1000, Herbert Xu wrote:
> On Thu, Sep 24, 2020 at 09:40:26AM +0200, Steffen Klassert wrote:
> >
> > This is yet another ipv4 mapped ipv6 address with IPsec socket policy
> > combination bug, and I'm sure it is not the last one. We could fix this
> > one by adding another check to match the address family of the policy
> > and the SA selector, but maybe it is better to think about how this
> > should work at all.
> >
> > We can have only one socket policy for each direction and that
> > policy accepts either ipv4 or ipv6. We treat this ipv4 mapped ipv6
> > address as ipv4 and pass it down the ipv4 stack, so this dual usage
> > will not work with a socket policy. Maybe we can require IPV6_V6ONLY
> > for sockets with policy attached. Thoughts?
>
> I'm looking at the history of this and it used to work at the start
> because you'd always interpret the flow object with a family. This
> appears to have been lost with 8444cf712c5f71845cba9dc30d8f530ff0d5ff83.
I'm sure it can be fixed to work with either ipv4 or ipv6.
If I understand that right, it should be possible to talk
ipv4 and ipv6 through that socket, but the policy will
accept only one address family.
> I'm working on a fix.
Thanks!
next prev parent reply other threads:[~2020-09-24 8:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 14:56 KASAN: stack-out-of-bounds Read in xfrm_selector_match (2) syzbot
2020-09-24 7:40 ` Steffen Klassert
2020-09-24 7:43 ` Herbert Xu
2020-09-24 8:02 ` Steffen Klassert [this message]
2020-09-25 3:07 ` Herbert Xu
2020-09-25 4:42 ` [PATCH] xfrm: Use correct address family in xfrm_state_find Herbert Xu
2020-09-28 5:07 ` Steffen Klassert
2020-09-28 2:21 ` KASAN: stack-out-of-bounds Read in xfrm_selector_match (2) Paul Moore
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=20200924080205.GD20687@gauss3.secunet.de \
--to=steffen.klassert@secunet.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=syzbot+577fbac3145a6eb2e7a5@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.