[{"id":1798330,"web_url":"http://patchwork.ozlabs.org/comment/1798330/","msgid":"","list_archive_url":null,"date":"2017-11-02T22:57:29","subject":"Re: [PATCH ipsec] xfrm: do unconditional template resolution before\n\tpcpu cache check","submitter":{"id":9088,"url":"http://patchwork.ozlabs.org/api/people/9088/","name":"Paul Moore","email":"paul@paul-moore.com"},"content":"On Thu, Nov 2, 2017 at 11:46 AM, Florian Westphal wrote:\n> Stephen Smalley says:\n> Since 4.14-rc1, the selinux-testsuite has been encountering sporadic\n> failures during testing of labeled IPSEC. git bisect pointed to\n> commit ec30d (\"xfrm: add xdst pcpu cache\").\n> The xdst pcpu cache is only checking that the policies are the same,\n> but does not validate that the policy, state, and flow match with respect\n> to security context labeling.\n> As a result, the wrong SA could be used and the receiver could end up\n> performing permission checking and providing SO_PEERSEC or SCM_SECURITY\n> values for the wrong security context.\n>\n> This fix makes it so that we always do the template resolution, and\n> then checks that the found states match those in the pcpu bundle.\n>\n> This has the disadvantage of doing a bit more work (lookup in state hash\n> table) if we can reuse the xdst entry (we only avoid xdst alloc/free)\n> but we don't add a lot of extra work in case we can't reuse.\n>\n> xfrm_pol_dead() check is removed, reasoning is that\n> xfrm_tmpl_resolve does all needed checks.\n>\n> Cc: Paul Moore \n> Fixes: ec30d78c14a813db39a647b6a348b428 (\"xfrm: add xdst pcpu cache\")\n> Reported-by: Stephen Smalley \n> Tested-by: Stephen Smalley \n> Signed-off-by: Florian Westphal \n> ---\n> net/xfrm/xfrm_policy.c | 42 ++++++++++++++++++++++++------------------\n> 1 file changed, 24 insertions(+), 18 deletions(-)\n\nThis looks reasonable and seems like probably the simplest approach to\nme. I'm building a test kernel with it now, but considering the time\nof day here, I probably will not be able to test it until tomorrow\nmorning; however it is important to note that Stephen did test this\nalready so please don't wait on my test results - we are likely to be\nrunning the same tests anyway.\n\nAcked-by: Paul Moore \n\n> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c\n> index 8cafb3c0a4ac..a2e531bf4f97 100644\n> --- a/net/xfrm/xfrm_policy.c\n> +++ b/net/xfrm/xfrm_policy.c\n> @@ -1787,19 +1787,23 @@ void xfrm_policy_cache_flush(void)\n> put_online_cpus();\n> }\n>\n> -static bool xfrm_pol_dead(struct xfrm_dst *xdst)\n> +static bool xfrm_xdst_can_reuse(struct xfrm_dst *xdst,\n> + struct xfrm_state * const xfrm[],\n> + int num)\n> {\n> - unsigned int num_pols = xdst->num_pols;\n> - unsigned int pol_dead = 0, i;\n> + const struct dst_entry *dst = &xdst->u.dst;\n> + int i;\n>\n> - for (i = 0; i < num_pols; i++)\n> - pol_dead |= xdst->pols[i]->walk.dead;\n> + if (xdst->num_xfrms != num)\n> + return false;\n>\n> - /* Mark DST_OBSOLETE_DEAD to fail the next xfrm_dst_check() */\n> - if (pol_dead)\n> - xdst->u.dst.obsolete = DST_OBSOLETE_DEAD;\n> + for (i = 0; i < num; i++) {\n> + if (!dst || dst->xfrm != xfrm[i])\n> + return false;\n> + dst = dst->child;\n> + }\n>\n> - return pol_dead;\n> + return xfrm_bundle_ok(xdst);\n> }\n>\n> static struct xfrm_dst *\n> @@ -1813,26 +1817,28 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy **pols, int num_pols,\n> struct dst_entry *dst;\n> int err;\n>\n> + /* Try to instantiate a bundle */\n> + err = xfrm_tmpl_resolve(pols, num_pols, fl, xfrm, family);\n> + if (err <= 0) {\n> + if (err != 0 && err != -EAGAIN)\n> + XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTPOLERROR);\n> + return ERR_PTR(err);\n> + }\n> +\n> xdst = this_cpu_read(xfrm_last_dst);\n> if (xdst &&\n> xdst->u.dst.dev == dst_orig->dev &&\n> xdst->num_pols == num_pols &&\n> - !xfrm_pol_dead(xdst) &&\n> memcmp(xdst->pols, pols,\n> sizeof(struct xfrm_policy *) * num_pols) == 0 &&\n> - xfrm_bundle_ok(xdst)) {\n> + xfrm_xdst_can_reuse(xdst, xfrm, err)) {\n> dst_hold(&xdst->u.dst);\n> + while (err > 0)\n> + xfrm_state_put(xfrm[--err]);\n> return xdst;\n> }\n>\n> old = xdst;\n> - /* Try to instantiate a bundle */\n> - err = xfrm_tmpl_resolve(pols, num_pols, fl, xfrm, family);\n> - if (err <= 0) {\n> - if (err != 0 && err != -EAGAIN)\n> - XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTPOLERROR);\n> - return ERR_PTR(err);\n> - }\n>\n> dst = xfrm_bundle_create(pols[0], xfrm, err, fl, dst_orig);\n> if (IS_ERR(dst)) {\n> --\n> 2.13.6\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=paul-moore-com.20150623.gappssmtp.com\n\theader.i=@paul-moore-com.20150623.gappssmtp.com\n\theader.b=\"lT2zumCu\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySgTW3QH2z9sRg\n\tfor ;\n\tFri, 3 Nov 2017 09:57:35 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S934609AbdKBW5c (ORCPT );\n\tThu, 2 Nov 2017 18:57:32 -0400","from mail-lf0-f67.google.com ([209.85.215.67]:55592 \"EHLO\n\tmail-lf0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S934578AbdKBW5b (ORCPT\n\t); Thu, 2 Nov 2017 18:57:31 -0400","by mail-lf0-f67.google.com with SMTP id e143so1163027lfg.12\n\tfor ; Thu, 02 Nov 2017 15:57:31 -0700 (PDT)","by 10.25.19.76 with HTTP; Thu, 2 Nov 2017 15:57:29 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=paul-moore-com.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=A0/AjvUX8h887ykb074wR7dhXgT18l2R9qpuL2Aq0Sg=;\n\tb=lT2zumCuke6eZrSclZlJhe2ab5qjYFFuLcujezVcEdvXVSU3JfmzR2hF1GhoDQM2Zp\n\t1eT11WkPOOlZTfLM4PeorhSzW0pSAOGJKdkL3mKs8Fm4VYDCg/BXxdkdTpEv5fofGPzA\n\tz4me4qb9YqtOudGUyGIp4CCGWtlKeRhLEfh6V3pKsxYx1CjUz4wH9PyG/wz22LhmXqch\n\tYizjs693VHWkQ5eRJZk1UhsOg07z3F4oGd8Ak0DIl7nbPKD1aQFKtQxGBy2G7KPWKPrU\n\tpEJjntXaWTnEPKTjxnS0/YBIrgympJ1gJiQEsTOFaY2Pksm+GO4gDRPs400yJqiwXE4k\n\tkT8g==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=A0/AjvUX8h887ykb074wR7dhXgT18l2R9qpuL2Aq0Sg=;\n\tb=JaJ5k+vi8XOj/s9BNrsCceALQo6zueLKGHDDdiSfUgvnGz9zCdlLOVXEv+zFFyFw7W\n\taRVPbiIoTbe1nexWik9JYXqqSKKaIOtSnW4xbG2ou2FisAjHRxNMbxPHF4dbwBv1+JBG\n\tjOp8NkNtNsyJICxeyJ6hWPorggGIINMX1mdy866wx/9nEqvYWIWd82H1cfi68No7SC4Q\n\t590DYIzGVQ2VpBLn83ZhssyRrRFWzFZDWY7KLJjOPUiQk/ftZT+XJQAr1yowItZPRc7D\n\tr7UVWR4/2uxxkPct0gNBc7jn7JWaLWu9Pl8H86oZAA+bWegeshJflg1kVt9MHF38Ibb4\n\tTexw==","X-Gm-Message-State":"AMCzsaV6aK4Jw7WxN6MvSSncBE86C4+C50x9696u4grof+8smCK2BBoa\n\t6BfIg7slO7NPjaWHMHKLgrhHHezzRL7B7YySkPoc4K4=","X-Google-Smtp-Source":"ABhQp+QwBcvXEqLoddLtRJQd28HyEKQzNdvoGMNBru957WAukPQqmH4syvkssj8MfEQPMhJx77glXpOzz1ZBH9ga8Eo=","X-Received":"by 10.46.16.10 with SMTP id j10mr2092145lje.13.1509663450253;\n\tThu, 02 Nov 2017 15:57:30 -0700 (PDT)","MIME-Version":"1.0","X-Originating-IP":"[108.49.102.27]","In-Reply-To":"<20171102154601.25590-1-fw@strlen.de>","References":"<20171102154601.25590-1-fw@strlen.de>","From":"Paul Moore ","Date":"Thu, 2 Nov 2017 18:57:29 -0400","Message-ID":"","Subject":"Re: [PATCH ipsec] xfrm: do unconditional template resolution before\n\tpcpu cache check","To":"Florian Westphal ","Cc":"netdev@vger.kernel.org, Stephen Smalley ,\n\tsteffen.klassert@secunet.com","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1798479,"web_url":"http://patchwork.ozlabs.org/comment/1798479/","msgid":"<20171103092740.GQ11292@secunet.com>","list_archive_url":null,"date":"2017-11-03T09:27:40","subject":"Re: [PATCH ipsec] xfrm: do unconditional template resolution before\n\tpcpu cache check","submitter":{"id":1442,"url":"http://patchwork.ozlabs.org/api/people/1442/","name":"Steffen Klassert","email":"steffen.klassert@secunet.com"},"content":"On Thu, Nov 02, 2017 at 06:57:29PM -0400, Paul Moore wrote:\n> On Thu, Nov 2, 2017 at 11:46 AM, Florian Westphal wrote:\n> > Stephen Smalley says:\n> > Since 4.14-rc1, the selinux-testsuite has been encountering sporadic\n> > failures during testing of labeled IPSEC. git bisect pointed to\n> > commit ec30d (\"xfrm: add xdst pcpu cache\").\n> > The xdst pcpu cache is only checking that the policies are the same,\n> > but does not validate that the policy, state, and flow match with respect\n> > to security context labeling.\n> > As a result, the wrong SA could be used and the receiver could end up\n> > performing permission checking and providing SO_PEERSEC or SCM_SECURITY\n> > values for the wrong security context.\n> >\n> > This fix makes it so that we always do the template resolution, and\n> > then checks that the found states match those in the pcpu bundle.\n> >\n> > This has the disadvantage of doing a bit more work (lookup in state hash\n> > table) if we can reuse the xdst entry (we only avoid xdst alloc/free)\n> > but we don't add a lot of extra work in case we can't reuse.\n> >\n> > xfrm_pol_dead() check is removed, reasoning is that\n> > xfrm_tmpl_resolve does all needed checks.\n> >\n> > Cc: Paul Moore \n> > Fixes: ec30d78c14a813db39a647b6a348b428 (\"xfrm: add xdst pcpu cache\")\n> > Reported-by: Stephen Smalley \n> > Tested-by: Stephen Smalley \n> > Signed-off-by: Florian Westphal \n> > ---\n> > net/xfrm/xfrm_policy.c | 42 ++++++++++++++++++++++++------------------\n> > 1 file changed, 24 insertions(+), 18 deletions(-)\n> \n> This looks reasonable and seems like probably the simplest approach to\n> me. I'm building a test kernel with it now, but considering the time\n> of day here, I probably will not be able to test it until tomorrow\n> morning; however it is important to note that Stephen did test this\n> already so please don't wait on my test results - we are likely to be\n> running the same tests anyway.\n> \n> Acked-by: Paul Moore \n\nPatch applied, thanks everyone!","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySxSf5ZFdz9sNc\n\tfor ;\n\tFri, 3 Nov 2017 20:27:46 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932461AbdKCJ1o (ORCPT );\n\tFri, 3 Nov 2017 05:27:44 -0400","from a.mx.secunet.com ([62.96.220.36]:35736 \"EHLO a.mx.secunet.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1754185AbdKCJ1n (ORCPT );\n\tFri, 3 Nov 2017 05:27:43 -0400","from localhost (localhost [127.0.0.1])\n\tby a.mx.secunet.com (Postfix) with ESMTP id 0A982201C8;\n\tFri, 3 Nov 2017 10:27:42 +0100 (CET)","from a.mx.secunet.com ([127.0.0.1])\n\tby localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id guiyGXeqGt_4; Fri, 3 Nov 2017 10:27:41 +0100 (CET)","from mail-essen-01.secunet.de (mail-essen-01.secunet.de\n\t[10.53.40.204])\n\t(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby a.mx.secunet.com (Postfix) with ESMTPS id 389032006F;\n\tFri, 3 Nov 2017 10:27:41 +0100 (CET)","from gauss2.secunet.de (10.182.7.193) by mail-essen-01.secunet.de\n\t(10.53.40.204) with Microsoft SMTP Server id 14.3.361.1;\n\tFri, 3 Nov 2017 10:27:40 +0100","by gauss2.secunet.de (Postfix, from userid 1000) id A2C2914031C;\n\tFri, 3 Nov 2017 10:27:40 +0100 (CET)"],"X-Virus-Scanned":"by secunet","Date":"Fri, 3 Nov 2017 10:27:40 +0100","From":"Steffen Klassert ","To":"Paul Moore ","CC":"Florian Westphal , ,\n\tStephen Smalley ","Subject":"Re: [PATCH ipsec] xfrm: do unconditional template resolution before\n\tpcpu cache check","Message-ID":"<20171103092740.GQ11292@secunet.com>","References":"<20171102154601.25590-1-fw@strlen.de>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-G-Data-MailSecurity-for-Exchange-State":"0","X-G-Data-MailSecurity-for-Exchange-Error":"0","X-G-Data-MailSecurity-for-Exchange-Sender":"23","X-G-Data-MailSecurity-for-Exchange-Server":"d65e63f7-5c15-413f-8f63-c0d707471c93","X-EXCLAIMER-MD-CONFIG":"2c86f778-e09b-4440-8b15-867914633a10","X-G-Data-MailSecurity-for-Exchange-Guid":"3FBEF126-F615-48E2-867F-29D8498DD3A6","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1804617,"web_url":"http://patchwork.ozlabs.org/comment/1804617/","msgid":"<1510692390.19398.20.camel@tycho.nsa.gov>","list_archive_url":null,"date":"2017-11-14T20:46:30","subject":"[regression, 4.14] xfrm: Fix stack-out-of-bounds read in\n\txfrm_state_find breaks selinux-testsuite","submitter":{"id":410,"url":"http://patchwork.ozlabs.org/api/people/410/","name":"Stephen Smalley","email":"sds@tycho.nsa.gov"},"content":"Hi,\n\n4.14 is failing the selinux-testsuite labeled IPSEC tests despite\nhaving just been fixed in commit cf37966751747727 (\"xfrm: do\nunconditional template resolution before pcpu cache check\"). The\nbreaking commit is the very next one, commit c9f3f813d462c72d (\"xfrm:\nFix stack-out-of-bounds read in xfrm_state_find.\"). Unlike the earlier\nbreakage, which caused use of the wrong SA, this one leads to a failure\non connect(). Running ip xfrm monitor during one of the failing tests\nshows the following:\nacquire proto ah \n  sel src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp sport 0 dport 65535\ndev lo \n  policy src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp \n        security context\nunconfined_u:unconfined_r:test_inet_client_t:s0-s0:c0.c1023 \n        dir out priority 0 ptype main \n        tmpl src 0.0.0.0 dst 0.0.0.0\n                proto ah reqid 0 mode transport\n\nExpired src 127.0.0.1 dst 0.0.0.0\n        proto ah spi 0x00000000 reqid 0 mode transport\n        replay-window 0 \n        sel src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp sport 0 dport\n65535 dev lo \n        hard 1\n\nOn the last working commit, connect() instead succeeds and ip xfrm\nmonitor shows the following:\nAsync event  (0x20)  timer expired \n\tsrc 127.0.0.1 dst 127.0.0.1  reqid 0x0 protocol ah  SPI 0x200\nAsync event  (0x10)  replay update \n\tsrc 127.0.0.1 dst 127.0.0.1  reqid 0x0 protocol ah  SPI 0x200\nAsync event  (0x10)  replay update \n\tsrc 127.0.0.1 dst 127.0.0.1  reqid 0x0 protocol ah  SPI 0x200\n\nReproducer:\n# Install a Fedora VM w/ SELinux enabled (default).\n$ git clone https://github.com/SELinuxProject/selinux-testsuite/\n# Make sure you have the requisite kernel config options enabled.\n$ cd linux\n$ ./scripts/kconfig/merge_config.sh .config ../selinux-\ntestsuite/defconfig\n$ make\n$ sudo make modules_install install\n$ sudo reboot\n# Install dependencies.\nsudo dnf install perl-Test perl-Test-Harness perl-Test-Simple selinux-\npolicy-devel gcc libselinux-devel net-tools netlabel_tools iptables\n# Build and run the tests\nsudo make test\n\nAfter running once as above, you can run just the inet socket tests\nagain via:\ncd tests/inet_socket\n./test","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yc00w3c4Xz9s83\n\tfor ;\n\tWed, 15 Nov 2017 07:46:40 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1756497AbdKNUqh (ORCPT );\n\tTue, 14 Nov 2017 15:46:37 -0500","from uphb19pa13.eemsg.mail.mil ([214.24.26.87]:2526 \"EHLO\n\tUSFB19PA16.eemsg.mail.mil\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1751197AbdKNUqf (ORCPT\n\t); Tue, 14 Nov 2017 15:46:35 -0500","from emsm-gh1-uea11.ncsc.mil ([214.29.60.3])\n\tby USFB19PA16.eemsg.mail.mil with ESMTP/TLS/AES256-SHA;\n\t14 Nov 2017 20:46:19 +0000","from tarius.tycho.ncsc.mil ([144.51.242.1])\n\tby emsm-gh1-uea11.NCSC.MIL with ESMTP; 14 Nov 2017 20:46:18 +0000","from moss-pluto.infosec.tycho.ncsc.mil (moss-pluto\n\t[192.168.25.131])\n\tby tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id vAEKkH6w005741;\n\tTue, 14 Nov 2017 15:46:17 -0500"],"X-IronPort-AV":"E=Sophos;i=\"5.44,396,1505779200\"; d=\"scan'208\";a=\"5953012\"","IronPort-PHdr":"9a23:V7StWB2pSZwoudd1smDT+DRfVm0co7zxezQtwd8ZsesWLvrxwZ3uMQTl6Ol3ixeRBMOAuqIC07KempujcFRI2YyGvnEGfc4EfD4+ouJSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgppPOT1HZPZg9iq2+yo9ZDeZwZFiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLdQgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QKsqUjq+8ahkVB7oiD8GNzEn9mHXltdwh79frB64uhBz35LYbISTOfVwZKPdec4RS3RHUMhfSidNBpqwY5YTA+YEO+tTsovzqEYUrRamBgeiGePhxCFGiHD006061PguHwbJ0wIvBN8OrHfZoc/pOKoITey4zq/FxijDYfNM3jf97ZDFfA09of6SRbJwcdTeyU8yHA3Yi1Wfs4jlPzeL2eUNrmOW6PFgWv+0i2M8twFwoiSgxscrioXTgIIV0UrL+T92wIYyO921UUh2asOqHptXsiGVLYp2QsU6TmFnuSY61r0GuYOgcyQQ1JsnwBvfZvqaeIaL+hLuTPudLDh3iX5/eL+zmgy+/Vavx+HiTMW4zVBHpTdfnNbWrHACzRnT59CCSvt640iuxy6C1xvW6uFYOUA0krfbK4I5zr4wiJUTtUPDEzfqmErslq+Wd1gk+vOy5+T7YrTpup+cN4huhgH4LqsugdCwDf49MggPW2iX4eW81Lv98k3lWLhGk/I7n6bDvJ3aOMgXvLC1DgBL3oo59hqzFzKm384ZnXkDIlJFYhWHj43xNlHVPf/4Fuyyg0iskTh3x/DGOaftApPWLnfZirvhcrF961BExAop0d9f/45UCq0GIP/rXE/+qsDYAQInPAyq2OvnFtp92Z0EWW6VAa+WLrnSsVmW6eIrOeWMY5UVuDnlIfg/+/HulWM5mUMafaSx05sWZmu1Hu96I0WDZXrjnNEBHX0XsQUgVObqkkGNUSZPZ3auWKIx/ik7B5i7DYfHXY2tmKaO3Dq/HpFPY2BGDVeMEW32eImeR/gMbyeSKNd7kjMYTbihV5Mh1Ra2uQ/h17poMOTU+iMGupLlztR15OnTmgsp9TxvEcudyX2NQnpvnmwWWzA2waZ/rlJhyluZzad4hPlYRpRv4KZyTgo0O5Pah89+AsvpVxjdNoOSVFuoTNigRzI1R8kqzsUSS11wEMikgwyF1C2vVftdr7WWANQR9aXG0jClP89gz17e3bQlylwhRdFCc2ahg/gs2RLUAtvyj0iBl6usPZ8Z1SrJ+XbLmXGCp2lEQQVwVuPDRnlZaUzI+4eqrnjeRqOjXOx0ejBKztSPf+4TM4Xk","X-IPAS-Result":"A2DDAADwVAta/wHyM5BdGgEBAQEBAgEBAQEIAQEBAYMKLGRuJ4N+ih+PMUyYCIIRHRCFGAKFAT8YAQEBAQEBAQEBAWoogjgkAYJCBiMPAUYQCRwCJgICVwYBiBeCEQ0QjRKdaIInixQBAQEBAQEBAQIBAQEBAQEBASCBD4IlggeBDocjAYZjgmMFiiqIWV2OVIdtjRmCFYoMhyFIiWqCO4p3HzhCgTEqCgIfCCMPgy0Jgl8pgWwjNohqAQEB","Message-ID":"<1510692390.19398.20.camel@tycho.nsa.gov>","Subject":"[regression, 4.14] xfrm: Fix stack-out-of-bounds read in\n\txfrm_state_find breaks selinux-testsuite","From":"Stephen Smalley ","To":"Steffen Klassert ,\n\tPaul Moore ","Cc":"Florian Westphal , netdev@vger.kernel.org","Date":"Tue, 14 Nov 2017 15:46:30 -0500","In-Reply-To":"<20171103092740.GQ11292@secunet.com>","References":"<20171102154601.25590-1-fw@strlen.de>\n\t\n\t<20171103092740.GQ11292@secunet.com>","Organization":"National Security Agency","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.22.6 (3.22.6-2.fc25) ","Mime-Version":"1.0","Content-Transfer-Encoding":"8bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1804788,"web_url":"http://patchwork.ozlabs.org/comment/1804788/","msgid":"<20171115054010.GS11292@secunet.com>","list_archive_url":null,"date":"2017-11-15T05:40:10","subject":"Re: [regression, 4.14] xfrm: Fix stack-out-of-bounds read in\n\txfrm_state_find breaks selinux-testsuite","submitter":{"id":1442,"url":"http://patchwork.ozlabs.org/api/people/1442/","name":"Steffen Klassert","email":"steffen.klassert@secunet.com"},"content":"On Tue, Nov 14, 2017 at 03:46:30PM -0500, Stephen Smalley wrote:\n> Hi,\n> \n> 4.14 is failing the selinux-testsuite labeled IPSEC tests despite\n> having just been fixed in commit cf37966751747727 (\"xfrm: do\n> unconditional template resolution before pcpu cache check\"). The\n> breaking commit is the very next one, commit c9f3f813d462c72d (\"xfrm:\n> Fix stack-out-of-bounds read in xfrm_state_find.\"). Unlike the earlier\n> breakage, which caused use of the wrong SA, this one leads to a failure\n> on connect(). Running ip xfrm monitor during one of the failing tests\n> shows the following:\n> acquire proto ah \n>   sel src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp sport 0 dport 65535\n> dev lo \n>   policy src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp \n>         security context\n> unconfined_u:unconfined_r:test_inet_client_t:s0-s0:c0.c1023 \n>         dir out priority 0 ptype main \n>         tmpl src 0.0.0.0 dst 0.0.0.0\n>                 proto ah reqid 0 mode transport\n\nYes, I see. This is because there are wildcard src and dst\naddresses on the template. I'll revert this one for now.\n\nI slowly start to think that the concept of having a socket\npolicy on a IPv6 socket that maps to IPv4 is fundamentally\nbroken. The bug I tried to fix here is not the first one\nthat were reported from syzkaller for this szenario and I\nfear it is not the last one.\n\nThanks for reporting this!","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ycCrg3gtrz9s5L\n\tfor ;\n\tWed, 15 Nov 2017 16:40:19 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1756575AbdKOFkQ (ORCPT );\n\tWed, 15 Nov 2017 00:40:16 -0500","from a.mx.secunet.com ([62.96.220.36]:44054 \"EHLO a.mx.secunet.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753782AbdKOFkN (ORCPT );\n\tWed, 15 Nov 2017 00:40:13 -0500","from localhost (localhost [127.0.0.1])\n\tby a.mx.secunet.com (Postfix) with ESMTP id 3FDC0201C3;\n\tWed, 15 Nov 2017 06:40:12 +0100 (CET)","from a.mx.secunet.com ([127.0.0.1])\n\tby localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id CnIKpbMOKtNc; Wed, 15 Nov 2017 06:40:11 +0100 (CET)","from mail-essen-01.secunet.de (mail-essen-01.secunet.de\n\t[10.53.40.204])\n\t(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby a.mx.secunet.com (Postfix) with ESMTPS id C73D52005D;\n\tWed, 15 Nov 2017 06:40:11 +0100 (CET)","from gauss2.secunet.de (10.182.7.193) by mail-essen-01.secunet.de\n\t(10.53.40.204) with Microsoft SMTP Server id 14.3.361.1;\n\tWed, 15 Nov 2017 06:40:10 +0100","by gauss2.secunet.de (Postfix, from userid 1000) id 7CE6614032F;\n\tWed, 15 Nov 2017 06:40:10 +0100 (CET)"],"X-Virus-Scanned":"by secunet","Date":"Wed, 15 Nov 2017 06:40:10 +0100","From":"Steffen Klassert ","To":"Stephen Smalley ","CC":"Paul Moore , Florian Westphal ,\n\t","Subject":"Re: [regression, 4.14] xfrm: Fix stack-out-of-bounds read in\n\txfrm_state_find breaks selinux-testsuite","Message-ID":"<20171115054010.GS11292@secunet.com>","References":"<20171102154601.25590-1-fw@strlen.de>\n\t\n\t<20171103092740.GQ11292@secunet.com>\n\t<1510692390.19398.20.camel@tycho.nsa.gov>","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<1510692390.19398.20.camel@tycho.nsa.gov>","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-G-Data-MailSecurity-for-Exchange-State":"0","X-G-Data-MailSecurity-for-Exchange-Error":"0","X-G-Data-MailSecurity-for-Exchange-Sender":"23","X-G-Data-MailSecurity-for-Exchange-Server":"d65e63f7-5c15-413f-8f63-c0d707471c93","X-EXCLAIMER-MD-CONFIG":"2c86f778-e09b-4440-8b15-867914633a10","X-G-Data-MailSecurity-for-Exchange-Guid":"3F1322AA-9D31-4F95-9420-7CD831F7E52C","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]