Received: by 10.192.165.148 with SMTP id m20csp3845437imm; Mon, 30 Apr 2018 07:22:48 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpkOVRBgWLn7Uw37iDrJ5zc7VeZ6Jakmm8dMwyERfQ8Y81biUIG+qBF7F/pMEfeuoAN92Ss X-Received: by 10.98.87.84 with SMTP id l81mr12244080pfb.56.1525098168943; Mon, 30 Apr 2018 07:22:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525098168; cv=none; d=google.com; s=arc-20160816; b=KAi64hkLSEYlQtN3bUVsrGSAE/gAyTfv/dy4xOPXHvcPqLr/YgagYYJHYF/nCT80xi Fg1t0fjULulcYPH+4l4sOq4Fy5cPTXlZ/adAokJaV+/jniysVhPzFKr+TJ8FT9h+l+VJ xy4PRXQESHhss3m2TS3AFlfiY1EX2EC6f8fJHJ2JtLT+yq5/zBme52o4PKAMJa578UXO 70fd2q0zZiYCUmFG8RIUcKsZclj0Q1x5OcSseVWhaiI6jkzYUaWMSRmYLaiTwDN+gaLE ag/N93nt0AuaqTpAT7CCPeugDIzzAgJY5VBiqp+K7PR4/kvGePl5Pswl7iyt0Y9q8XMP +KNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=mxlp3FHzlUs6UkdacAEOTyUd3zLDjdqQYKFeoD8ffvM=; b=w7Ss3MqTCMniMQLIgVrL9ZxqBcpB0R2/2hydgYkt84AUTidEsq3bMqtIobEbyg56jm qfnS2NjjEBzvti1lO7W+6oVVg6uQfM6N02W591+VDspe2EOHik1j18Q9K6fiJs197zyG 4y9Jcrg1GtuE/y0qBFbaqKxYE6OCwi1h/EBg0p8Kirkg2y0Yrb/dibyIp0Y+p8KYusq2 EQPkeVZ90ldOThQHgzH+ip/z7z1ZAhqy/YIK5bhbpzQzNGLQyhhQ0nL3NsPnpEJY7TZH WwnX3EFDsAOtbs8h7XTjE6tSj69fr2w76V481O+wfFvn1rmJV3tvR1pgij+EH0KaqK0y UnRA== 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 h32-v6si7455628pld.170.2018.04.30.07.22.34; Mon, 30 Apr 2018 07:22:48 -0700 (PDT) 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 S1754358AbeD3OVK (ORCPT + 99 others); Mon, 30 Apr 2018 10:21:10 -0400 Received: from dispatch1-us1.ppe-hosted.com ([67.231.154.164]:53124 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753759AbeD3OVI (ORCPT ); Mon, 30 Apr 2018 10:21:08 -0400 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id A4A6114008E; Mon, 30 Apr 2018 14:21:03 +0000 (UTC) Received: from ec-desktop.uk.solarflarecom.com (10.17.20.45) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 30 Apr 2018 07:20:57 -0700 Subject: Re: [PATCH] ethtool: fix a potential missing-check bug To: Wenwen Wang CC: Kangjie Lu , "David S. Miller" , Florian Fainelli , Andrew Lunn , Russell King , Inbar Karmy , Eugenia Emantayev , Al Viro , Yury Norov , Vidya Sagar Ravipati , Alan Brady , "Stephen Hemminger" , "open list:NETWORKING [GENERAL]" , open list References: <1525051915-31944-1-git-send-email-wang6495@umn.edu> From: Edward Cree Message-ID: <00aa634b-edc0-220d-47d1-551c73af9f3b@solarflare.com> Date: Mon, 30 Apr 2018 15:20:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1525051915-31944-1-git-send-email-wang6495@umn.edu> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [10.17.20.45] X-MDID: 1525098066-1oYQh2zyq2r5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/04/18 02:31, Wenwen Wang wrote: > In ethtool_get_rxnfc(), the object "info" is firstly copied from > user-space. If the FLOW_RSS flag is set in the member field flow_type of > "info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from > user-space because FLOW_RSS is newer and has new definition, as mentioned > in the comment. However, given that the user data resides in user-space, a > malicious user can race to change the data after the first copy. By doing > so, the user can inject inconsistent data. For example, in the second > copy, the FLOW_RSS flag could be cleared in the field flow_type of "info". > In the following execution, "info" will be used in the function > ops->get_rxnfc(). Such inconsistent data can potentially lead to unexpected > information leakage since ops->get_rxnfc() will prepare various types of > data according to flow_type, and the prepared data will be eventually > copied to user-space. This inconsistent data may also cause undefined > behaviors based on how ops->get_rxnfc() is implemented. I'm not sure there's actually an issue here, since the only purpose of the  FLOW_RSS check is to avoid faulting/trampling user memory when the user  process only has the short version of 'info'. If userland subsequently removes the FLOW_RSS flag, then all that will  happen is that info_size is larger than it ought to be; that cannot affect  ops->get_rxnfc() since it isn't passed; the op should already be treating  'info' as unsafe/user-controlled. The only way this could lead to information leakage would be if in the non-  FLOW_RSS case ops->get_rxnfc() was writing things it shouldn't into the  latter part of 'info' and was getting away with it so far as that was  never copied_to_user; that seems improbable to me, but I suppose you might  want to do the check anyway as belt-and-braces security. (A cleaner approach might be to only copy_from_user() the extra region of  'info', leaving the previously-copied part alone.  That way each byte is  only copied_from_user once and thus cannot change.) -Ed > This patch re-verifies the flow_type field of "info" after the second copy. > If the value is not as expected, an error code will be returned. > > Signed-off-by: Wenwen Wang > --- > net/core/ethtool.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/core/ethtool.c b/net/core/ethtool.c > index 03416e6..a121034 100644 > --- a/net/core/ethtool.c > +++ b/net/core/ethtool.c > @@ -1032,6 +1032,8 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev, > info_size = sizeof(info); > if (copy_from_user(&info, useraddr, info_size)) > return -EFAULT; > + if (!(info.flow_type & FLOW_RSS)) > + return -EINVAL; > } > > if (info.cmd == ETHTOOL_GRXCLSRLALL) {