Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp4720815imm; Mon, 15 Oct 2018 21:41:14 -0700 (PDT) X-Google-Smtp-Source: ACcGV60LLl8/AlrAh05GtQt9Hhx2KFl8FHXF1CUvwvcs5P8mnBQSvl84Vf9HU2l6sky6lqR5zjZB X-Received: by 2002:a17:902:9a94:: with SMTP id w20-v6mr7698516plp.115.1539664874895; Mon, 15 Oct 2018 21:41:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539664874; cv=none; d=google.com; s=arc-20160816; b=gtGQrKSLFtbp+a7SXKGQCk11fDzKpjS7JZajLe0U4YUN+fzxHV6NPvaXddqGcg2r5N 6QJsJZA1lEBDAy83VS9kflfnHdryfY37l/6B04sVkeO1BECg+LTgL/r0+Vxahb//W2rk 3mc/7SNGVEsbKQMfaGu8BWH5faoJk7zMXCzQlU2nfhZHmv3+b/HLVbAHQup0txCgJ2RN 0cZ0FRsKhlnaiy0+1Wg/07zDSr4q3hQRpDQOR5IVhvq7aRC6tigR69+ys4cHjZEqKA7q BLo1jqoXVAYPYcja/5LolxvagtDpgY73XVcecaE7te7XF4YosLAYCHjneJ4PoHg/322i oA3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=XfZDQFsMfcC+nZgJAELsuVyEmcrD7Kpy5sIN8j2fJec=; b=XtyDDtpt2LkOtQAtb47uYvCTNDKo5qE53fCm0shI9oft0vW1j1qyg7GDmGFXXQ0vaH sVDhaqL0rgFUOm7HUEaLER4g3ZJRonGQoofNUsBrWKDvHc46gmKZ7LACniAtghq8SMKS VKRNmEn9AZ4xCi0SQ8j2a34onInlNP62SPuAlqz0BNs0aNSca9MpspNypXW04DsJ/PzD oyq8rhqRNCkdiHxXOakt0kAUo+LN1VvQ+JAG163EvcXfxmwExmUKiTpLM2vyjhGQnQWW 9RBjPWSwlnC1422KqwQySnpEATKlMZ79jgvj2+Wz4yxcc1tcsZ6rTMGCxoDBKIlt00TD yESQ== 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 d9-v6si12709139pll.414.2018.10.15.21.40.59; Mon, 15 Oct 2018 21:41:14 -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 S1727485AbeJPM1t (ORCPT + 99 others); Tue, 16 Oct 2018 08:27:49 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:42948 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726780AbeJPM1t (ORCPT ); Tue, 16 Oct 2018 08:27:49 -0400 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::cf9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id F376514513042; Mon, 15 Oct 2018 21:39:18 -0700 (PDT) Date: Mon, 15 Oct 2018 21:39:18 -0700 (PDT) Message-Id: <20181015.213918.1656394276439267836.davem@davemloft.net> To: wang6495@umn.edu Cc: kjlu@umn.edu, f.fainelli@gmail.com, keescook@chromium.org, andrew@lunn.ch, ecree@solarflare.com, ilyal@mellanox.com, ynorov@caviumnetworks.com, alan.brady@intel.com, stephen@networkplumber.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ethtool: fix a privilege escalation bug From: David Miller In-Reply-To: <1539013777-1625-1-git-send-email-wang6495@umn.edu> References: <1539013777-1625-1-git-send-email-wang6495@umn.edu> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 15 Oct 2018 21:39:19 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Wenwen Wang Date: Mon, 8 Oct 2018 10:49:35 -0500 > In dev_ethtool(), the eth command 'ethcmd' is firstly copied from the > use-space buffer 'useraddr' and checked to see whether it is > ETHTOOL_PERQUEUE. If yes, the sub-command 'sub_cmd' is further copied from > the user space. Otherwise, 'sub_cmd' is the same as 'ethcmd'. Next, > according to 'sub_cmd', a permission check is enforced through the function > ns_capable(). For example, the permission check is required if 'sub_cmd' is > ETHTOOL_SCOALESCE, but it is not necessary if 'sub_cmd' is > ETHTOOL_GCOALESCE, as suggested in the comment "Allow some commands to be > done by anyone". The following execution invokes different handlers > according to 'ethcmd'. Specifically, if 'ethcmd' is ETHTOOL_PERQUEUE, > ethtool_set_per_queue() is called. In ethtool_set_per_queue(), the kernel > object 'per_queue_opt' is copied again from the user-space buffer > 'useraddr' and 'per_queue_opt.sub_command' is used to determine which > operation should be performed. Given that the buffer 'useraddr' is in the > user space, a malicious user can race to change the sub-command between the > two copies. In particular, the attacker can supply ETHTOOL_PERQUEUE and > ETHTOOL_GCOALESCE to bypass the permission check in dev_ethtool(). Then > before ethtool_set_per_queue() is called, the attacker changes > ETHTOOL_GCOALESCE to ETHTOOL_SCOALESCE. In this way, the attacker can > bypass the permission check and execute ETHTOOL_SCOALESCE. > > This patch enforces a check in ethtool_set_per_queue() after the second > copy from 'useraddr'. If the sub-command is different from the one obtained > in the first copy in dev_ethtool(), an error code EINVAL will be returned. > > Signed-off-by: Wenwen Wang Applied and queued up for -stable.