Received: by 10.223.185.116 with SMTP id b49csp1137082wrg; Fri, 23 Feb 2018 12:35:19 -0800 (PST) X-Google-Smtp-Source: AH8x226iMV0qXoldqJcyDy14tblQy04tyzRMPTuzeeLxytjFk640PSJUVdyXKkNKR0NJrfUMD8m7 X-Received: by 2002:a17:902:6c0e:: with SMTP id q14-v6mr2804307plk.445.1519418119311; Fri, 23 Feb 2018 12:35:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519418119; cv=none; d=google.com; s=arc-20160816; b=GLscdosISPCf29sc0gzHBeIvK0WKLMpx4Lijpj8yM3b1turqQpdEB6lkeAu9cuCiGv AveGDLq1A2XS6w/bood6k6Ytku2Yafw1cnDHex7+1KS67infBGJf9JA1U6sP89vYqI8s LqaVqc8puVujpONqEEzwpz4gy5SYDCbVntfDriGP0BQ/Ufg//9Rn6SfgHUGDo0pY5yPS IBpq1KmHhhuzmhjtVktTW654MoJd6T5piCjWh3MqdRHXIuCdm45TVHyh2GiJNwyese++ 0q23KmOt76FSEbNvaNqBBBkADpMUhF7ItSc6GLyRr3LzLsrJH4Xo2xwrbCwPKGWdABnd 9trw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=RuFfwSj04lyCB694mBAsAu8SvVdGgxVM5npkUFApswM=; b=vPH71IrKh1ekJUKRMEbqEXBirddJpD2JdBcQo/I/nVcy62oC2vgxQ7QRSOwhabh5KZ QoMBflOGTWKAEcqJT6MQSK3HDjS5XwivOiUTW2qadyPuR6frJbqilX5p7t0/LSGl+JB2 uUzX+3oNpsMhZPNppI1E7VkwO/5ZB0tHEC8L8SeYW0cdEvCrbDb4e6mkTVBFGZpUTsJs TxzYFXMKzuMAXdgwVr3SVnQl5wQIwMXsLhDe0nGLonSibQ8ZkLJw6iE2+g5fytRjMish VJhYhqvu3f/hnyaI0YViB4LS2XTsW6QVjP4jQW/tZn2uKZhnBYvSs7IQgBIla3e1g2yW RE9w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a34-v6si2279783pld.505.2018.02.23.12.35.05; Fri, 23 Feb 2018 12:35:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753759AbeBWSfM (ORCPT + 99 others); Fri, 23 Feb 2018 13:35:12 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:37184 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751949AbeBWSfK (ORCPT ); Fri, 23 Feb 2018 13:35:10 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id BEDF5124C; Fri, 23 Feb 2018 18:35:09 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Steffen Klassert , Sasha Levin Subject: [PATCH 4.4 055/193] xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies. Date: Fri, 23 Feb 2018 19:24:48 +0100 Message-Id: <20180223170334.611498608@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180223170325.997716448@linuxfoundation.org> References: <20180223170325.997716448@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Steffen Klassert [ Upstream commit 732706afe1cc46ef48493b3d2b69c98f36314ae4 ] On policies with a transport mode template, we pass the addresses from the flowi to xfrm_state_find(), assuming that the IP addresses (and address family) don't change during transformation. Unfortunately our policy template validation is not strict enough. It is possible to configure policies with transport mode template where the address family of the template does not match the selectors address family. This lead to stack-out-of-bound reads because we compare arddesses of the wrong family. Fix this by refusing such a configuration, address family can not change on transport mode. We use the assumption that, on transport mode, the first templates address family must match the address family of the policy selector. Subsequent transport mode templates must mach the address family of the previous template. Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- net/xfrm/xfrm_user.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -1376,11 +1376,14 @@ static void copy_templates(struct xfrm_p static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family) { + u16 prev_family; int i; if (nr > XFRM_MAX_DEPTH) return -EINVAL; + prev_family = family; + for (i = 0; i < nr; i++) { /* We never validated the ut->family value, so many * applications simply leave it at zero. The check was @@ -1392,6 +1395,12 @@ static int validate_tmpl(int nr, struct if (!ut[i].family) ut[i].family = family; + if ((ut[i].mode == XFRM_MODE_TRANSPORT) && + (ut[i].family != prev_family)) + return -EINVAL; + + prev_family = ut[i].family; + switch (ut[i].family) { case AF_INET: break;