Received: by 10.223.185.116 with SMTP id b49csp1097464wrg; Fri, 23 Feb 2018 11:53:52 -0800 (PST) X-Google-Smtp-Source: AH8x226TBHKbrbK0RQZhk9ehcLRAGq+ww26InCTH1rzofcTE9Pdd+FJlvNNhj8vb2HZbYqDkq566 X-Received: by 2002:a17:902:a712:: with SMTP id w18-v6mr2593428plq.81.1519415632715; Fri, 23 Feb 2018 11:53:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519415632; cv=none; d=google.com; s=arc-20160816; b=IHOLKmjOqhB/MwELvxB+DIGm2SasKK/ZvyTVHgp2gK77ivj0kFDplyxyhkj6i+d6qW X4ek+JP/39SaW/W9e39shvMr3APhPnV7HUm1ZH4bHoAHceNfWgkJJ21IJ6VSxJRCAYli awtkm2J+qo3LJMpCHp9rpEmTHe6xPKbkUsoORfTfs+dXAf8hJMixnM5RoQQIZeTA424m qviOlpJCTvDZ/7j3kpHsDlqYUTCevTuRy1syYoLqB3fCEYjYFpK/yclyHlugGzefDEEb Gl/VRJtbmJmWZ764uECebYBhwOetom7brbeDp+OFpnSO0joSB7ZtbeDGklsyICdyWPZN aDVQ== 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=vtjNE0slaih/W6IYUn/yOTcbt0WC9a/z2yBHDkTgWww=; b=nWLVw3IMjmrcIbzEEzRtD9vkwt6ofRGDt4DaYaiLAYVIFWWONnmdmqAQVRy3bRumBh UJL+lBk/N4ST51P9zCzDsV5Iupuzwr75W/LwDB9ggYx21oKsHWps/DjFiIju1tdLRuYr AiLcYAFpng1Jya/boDCSCkdVNLEpELJy0h64lx1fM7q3EV5fSExYRRofTmu6d2YieePa Jx7Yre58klpy0V18DUm1oiPHu5JgxetojGX15dKNaVFOM7ol/vRwBTQR3zM+5bfFwBik WG9ZU2nm1D1/Al7rfREkXcIv5YkatVkYkAQHVgbBk9qun+XoeqGbNeV/hqero7+XYCdx CYbQ== 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 z16-v6si1201386plo.171.2018.02.23.11.53.38; Fri, 23 Feb 2018 11:53:52 -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 S933866AbeBWSpo (ORCPT + 99 others); Fri, 23 Feb 2018 13:45:44 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:43428 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933550AbeBWSpl (ORCPT ); Fri, 23 Feb 2018 13:45:41 -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 1D8BE1261; Fri, 23 Feb 2018 18:45:40 +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.9 077/145] xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies. Date: Fri, 23 Feb 2018 19:26:23 +0100 Message-Id: <20180223170734.699697306@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180223170724.669759283@linuxfoundation.org> References: <20180223170724.669759283@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.9-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 @@ -1380,11 +1380,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 @@ -1396,6 +1399,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;