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: Mon, 6 Nov 2017 11:16:46 +0100 [thread overview]
Message-ID: <20171106101646.GG23855@secunet.com> (raw)
In-Reply-To: <20171103121012.GA23855@secunet.com>
On Fri, Nov 03, 2017 at 01:10:12PM +0100, Steffen Klassert wrote:
> On Thu, Nov 02, 2017 at 01:25:28PM +0100, Florian Westphal wrote:
> > Steffen Klassert <steffen.klassert@secunet.com> wrote:
> >
> > > I'd propose to use the addresses from the template unconditionally,
> > > like the (untested) patch below does.
> > >
> > > Unfortunalely the reproducer does not work with my config,
> > > sendto returns EAGAIN. Could anybody try this patch?
> >
> > The reproducer no longer causes KASAN spew with your patch,
> > but i don't have a test case that actually creates/uses a tunnel.
>
> The patch passed my standard tests, so I tend apply it
> after a day in the ipsec/testing branch.
FYI: I've just applied the patch below to the ipsec tree.
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>
---
net/xfrm/xfrm_policy.c | 29 +++++++++++------------------
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index a2e531b..6eb228a 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1361,36 +1361,29 @@ xfrm_tmpl_resolve_one(struct xfrm_policy *policy, const struct flowi *fl,
struct net *net = xp_net(policy);
int nx;
int i, error;
- xfrm_address_t *daddr = xfrm_flowi_daddr(fl, family);
- xfrm_address_t *saddr = xfrm_flowi_saddr(fl, family);
xfrm_address_t tmp;
for (nx = 0, i = 0; i < policy->xfrm_nr; i++) {
struct xfrm_state *x;
- xfrm_address_t *remote = daddr;
- xfrm_address_t *local = saddr;
+ xfrm_address_t *local;
+ xfrm_address_t *remote;
struct xfrm_tmpl *tmpl = &policy->xfrm_vec[i];
- if (tmpl->mode == XFRM_MODE_TUNNEL ||
- tmpl->mode == XFRM_MODE_BEET) {
- remote = &tmpl->id.daddr;
- local = &tmpl->saddr;
- if (xfrm_addr_any(local, tmpl->encap_family)) {
- error = xfrm_get_saddr(net, fl->flowi_oif,
- &tmp, remote,
- tmpl->encap_family, 0);
- if (error)
- goto fail;
- local = &tmp;
- }
+ remote = &tmpl->id.daddr;
+ local = &tmpl->saddr;
+ if (xfrm_addr_any(local, tmpl->encap_family)) {
+ error = xfrm_get_saddr(net, fl->flowi_oif,
+ &tmp, remote,
+ tmpl->encap_family, 0);
+ if (error)
+ goto fail;
+ local = &tmp;
}
x = xfrm_state_find(remote, local, fl, tmpl, policy, &error, family);
if (x && x->km.state == XFRM_STATE_VALID) {
xfrm[nx++] = x;
- daddr = remote;
- saddr = local;
continue;
}
if (x) {
--
2.7.4
next prev parent reply other threads:[~2017-11-06 10:16 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 [this message]
2017-11-06 10:31 ` Dmitry Vyukov
2017-11-15 11:36 ` Steffen Klassert
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=20171106101646.GG23855@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).