From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steffen Klassert <steffen.klassert@secunet.com>
Subject: Re: [regression, 4.14] xfrm: Fix stack-out-of-bounds read in
 xfrm_state_find breaks selinux-testsuite
Date: Wed, 15 Nov 2017 06:40:10 +0100
Message-ID: <20171115054010.GS11292@secunet.com>
References: <20171102154601.25590-1-fw@strlen.de>
 <CAHC9VhSikfCPf6_c-ts6FLsw56k_tpBGGMDD4909zP=V_Va+tQ@mail.gmail.com>
 <20171103092740.GQ11292@secunet.com>
 <1510692390.19398.20.camel@tycho.nsa.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Cc: Paul Moore <paul@paul-moore.com>, Florian Westphal <fw@strlen.de>,
        <netdev@vger.kernel.org>
To: Stephen Smalley <sds@tycho.nsa.gov>
Return-path: <netdev-owner@vger.kernel.org>
Received: from a.mx.secunet.com ([62.96.220.36]:44054 "EHLO a.mx.secunet.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753782AbdKOFkN (ORCPT <rfc822;netdev@vger.kernel.org>);
        Wed, 15 Nov 2017 00:40:13 -0500
Content-Disposition: inline
In-Reply-To: <1510692390.19398.20.camel@tycho.nsa.gov>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Tue, Nov 14, 2017 at 03:46:30PM -0500, Stephen Smalley wrote:
> Hi,
> 
> 4.14 is failing the selinux-testsuite labeled IPSEC tests despite
> having just been fixed in commit cf37966751747727 ("xfrm: do
> unconditional template resolution before pcpu cache check").  The
> breaking commit is the very next one, commit c9f3f813d462c72d ("xfrm:
> Fix stack-out-of-bounds read in xfrm_state_find.").  Unlike the earlier
> breakage, which caused use of the wrong SA, this one leads to a failure
> on connect(). Running ip xfrm monitor during one of the failing tests
> shows the following:
> acquire proto ah 
>   sel src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp sport 0 dport 65535
> dev lo 
>   policy src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp 
>         security context
> unconfined_u:unconfined_r:test_inet_client_t:s0-s0:c0.c1023 
>         dir out priority 0 ptype main 
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                 proto ah reqid 0 mode transport

Yes, I see. This is because there are wildcard src and dst
addresses on the template. I'll revert this one for now.

I slowly start to think that the concept of having a socket
policy on a IPv6 socket that maps to IPv4 is fundamentally
broken. The bug I tried to fix here is not the first one
that were reported from syzkaller for this szenario and I
fear it is not the last one.

Thanks for reporting this!