All of lore.kernel.org
 help / color / mirror / Atom feed
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.

      parent reply	other threads:[~2017-11-15 11:37 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.com \
    --cc=bot+19b21aa652248382e2b8cbb81fa1cdc03b4bda01@syzkaller.appspotmail.com \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=thomas.egerer@secunet.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.