Received: by 10.223.185.116 with SMTP id b49csp1063785wrg; Fri, 23 Feb 2018 11:15:14 -0800 (PST) X-Google-Smtp-Source: AH8x224tO6mUPOy2MT4dh2PyegFO5vOq2ovRKOS9ou0+utclDoM5ap8VbrZq7T4ULOwwQGc7ivBA X-Received: by 10.98.200.131 with SMTP id i3mr2779099pfk.40.1519413314503; Fri, 23 Feb 2018 11:15:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519413314; cv=none; d=google.com; s=arc-20160816; b=apTfsLV+0SGBsq65u+k6NV0J8kGR0qIDHOwu38ZpSe86hW1uXQb4Wv4hS0xKH8pLi0 hZ99XFo6wbBmLljvAxH4huqWYeLxm9ydnzpKqq/qJAXPlfuFhNWyKxQdTOwcyVTrG2GQ 9E+GtGo/QIkr3pJQv82g+ifPOuYGzwbdYwnFbVvug+kmaSGHeeHKnAtCHN5kwij7ukgT Ex+TSCNRWH2ZqOcfMJja34OX6OZ2z1aGHHBr1vqHaj3LAlg7Nj9Po7lQODVqze/hgT6v s8EItFWfGp6czQcDb3HwulAhS6D0ihW4djgCU5iuEwWab8vQnwd+i8XSY0k0ZsIFxkNr yJtg== 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=8ayaxIabUW7nDTaAQQGxrnubpiHhfss1fsRh+4/n83w=; b=AA/Zyiu6MkjgZzQ9MNe5Z466Jk7Q5UVMl9H0mCagXFGEvKLEGFbLwPlQzAGYgcsX0/ k8XVz5oxqfmmB86aaBPd5YfzA+IhnuqzmYCJV+z25Yx02pRNunXmt1qo6ROvgTpn+YJ7 I2i3rYuvTW/63aRK62RUa/LS6eTl81o3P6d2S7qxhllIin71+n8BtEyHLvRZUN3GziCj 1jCy+OKsYaGIjv8xAiNmUFk7Es4xsCkUG+WMZ1oIw5z8Ir7v7tDd7XPN+vnBwirLnknF t/Qqlz/FaIrCK1hhuA6KCYd+JnHrw0kgWqLAIPnBjRVsys0JrUhXfqvwr5yJbte0Myrp ArNg== 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 y6si1852686pgo.735.2018.02.23.11.14.59; Fri, 23 Feb 2018 11:15:14 -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 S1751960AbeBWTO0 (ORCPT + 99 others); Fri, 23 Feb 2018 14:14:26 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:48348 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935571AbeBWSzn (ORCPT ); Fri, 23 Feb 2018 13:55:43 -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 2F90F128B; Fri, 23 Feb 2018 18:55:43 +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.14 140/159] xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies. Date: Fri, 23 Feb 2018 19:27:28 +0100 Message-Id: <20180223170759.959741207@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180223170743.086611315@linuxfoundation.org> References: <20180223170743.086611315@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.14-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 @@ -1417,11 +1417,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 @@ -1433,6 +1436,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;