From: Steffen Klassert <steffen.klassert@secunet•com>
To: Florian Westphal <fw@strlen•de>
Cc: syzbot
<bot+19b21aa652248382e2b8cbb81fa1cdc03b4bda01@syzkaller•appspotmail.com>,
<davem@davemloft•net>, <herbert@gondor•apana.org.au>,
<linux-kernel@vger•kernel.org>, <netdev@vger•kernel.org>,
<syzkaller-bugs@googlegroups•com>, <thomas.egerer@secunet•com>
Subject: Re: KASAN: stack-out-of-bounds Read in xfrm_state_find (2)
Date: Wed, 15 Nov 2017 12:36:56 +0100 [thread overview]
Message-ID: <20171115113656.GU11292@secunet.com> (raw)
In-Reply-To: <20171106101646.GG23855@secunet.com>
On Mon, Nov 06, 2017 at 11:16:46AM +0100, Steffen Klassert wrote:
>
> Subject: [PATCH ipsec] xfrm: Fix stack-out-of-bounds read in xfrm_state_find.
>
> When we do tunnel or beet mode, we pass saddr and daddr from the
> template to xfrm_state_find(), this is ok. On transport mode,
> we pass the addresses from the flowi, assuming that the IP
> addresses (and address family) don't change during transformation.
> This assumption is wrong in the IPv4 mapped IPv6 case, packet
> is IPv4 and template is IPv6. Fix this by using the addresses
> from the template unconditionally.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet•com>
I had to revert this, it broke transport mode when the policy
template has no src and dst addresses configured. I'll come up
with some other fix, probably don't do policy/flow maching
when a socket policies address family does not match the
flow address family. This should hopefully fix this whole
class of IPv4 mapped IPv6 with socket policy bugs.
prev parent reply other threads:[~2017-11-15 11:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 17:45 KASAN: stack-out-of-bounds Read in xfrm_state_find (2) syzbot
2017-11-01 22:06 ` Florian Westphal
2017-11-02 10:32 ` Steffen Klassert
2017-11-02 12:25 ` Florian Westphal
2017-11-03 12:10 ` Steffen Klassert
2017-11-06 10:16 ` Steffen Klassert
2017-11-06 10:31 ` Dmitry Vyukov
2017-11-15 11:36 ` Steffen Klassert [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=20171115113656.GU11292@secunet.com \
--to=steffen.klassert@secunet$(echo .)com \
--cc=bot+19b21aa652248382e2b8cbb81fa1cdc03b4bda01@syzkaller$(echo .)appspotmail.com \
--cc=davem@davemloft$(echo .)net \
--cc=fw@strlen$(echo .)de \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=syzkaller-bugs@googlegroups$(echo .)com \
--cc=thomas.egerer@secunet$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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