Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp795474imm; Fri, 5 Oct 2018 11:55:44 -0700 (PDT) X-Google-Smtp-Source: ACcGV639Wq3t2P+lK6byrJecSZbeQX5FU3vnL+eTMf+HySgyhEXubhRTHmCNshRdK7x7GDACf57R X-Received: by 2002:a17:902:ac89:: with SMTP id h9-v6mr12626556plr.174.1538765744252; Fri, 05 Oct 2018 11:55:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538765744; cv=none; d=google.com; s=arc-20160816; b=TtSGB9QR/I+Kp6J60hD69EOqN3LldRfcPKpVUVWYCKmJgpQ7dcyPXC+jn9LG1BvQPL EXbXwTAbX0/gxVlO1hoJ1kE6qT9UFq9/uebTiakE12dCZ7EfUdspODL9FUPKHopVDxI3 1UTLCVZShUak44KtpBoGPQAicM0pQ4hdZaKeYCfUUadF9HE201o4lG2r5PmC6B5AFLk+ Vhl4RyhcmGtzav4teyNkLlXmxXuCDfxtG6J2DqNSdSkvvW2imKlE9kalr1VQCBfnN3Fq wcgQ3bTvmNh5i3d6TQO235IZfzHk5RauTPv3Lomsv8naacRbd8bW+SrzG426cfCt6nhR 8J4Q== 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=VUPjn4oMKyQ2guZgCFawUk5pMywBm4AOvzHnwuKB7CM=; b=hP5nRIrqeiv/XQ2e7FTNtS5Ea1EfqDCns+cmd9tu+68/A+SEG8mnaaaNwAmbWJAtVo L60YccvqWmJWrKS9qSSEexdIv4YQIGLRtCRq1DbNGCsKRCOWgYdxjy4Ofm05zonUvo8o E8i2gcAAWg+TJA7TXV++asN5B20l1M0WczoEA1J4VM/L5ASE0Un3/4kaUX8nX1GTlW/3 0ZmzLtOGYJWQuWALWfTqNTjH8E3pUKwp20BO4IJDk55DsamICYfHNgVDHekbXj6Nf7nb KagHem3GeuU554tAXodWgfyhvzW7Yrr1yNPqWx+LHTy/SExgNgrVTBgn9i8jVYGEcDQN ++9A== 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 t21-v6si10221882plj.352.2018.10.05.11.55.29; Fri, 05 Oct 2018 11:55:44 -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 S1729095AbeJFBzX (ORCPT + 99 others); Fri, 5 Oct 2018 21:55:23 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:44442 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728044AbeJFBzX (ORCPT ); Fri, 5 Oct 2018 21:55:23 -0400 Received: from localhost (c-67-183-145-105.hsd1.wa.comcast.net [67.183.145.105]) (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 1AC0C13ADF954; Fri, 5 Oct 2018 11:55:22 -0700 (PDT) Date: Fri, 05 Oct 2018 11:55:21 -0700 (PDT) Message-Id: <20181005.115521.804633180942667200.davem@davemloft.net> To: wang6495@umn.edu Cc: kjlu@umn.edu, jpr@f6fbb.org, linux-hams@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] yam: fix a missing-check bug From: David Miller In-Reply-To: <1538755176-22355-1-git-send-email-wang6495@umn.edu> References: <1538755176-22355-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]); Fri, 05 Oct 2018 11:55:22 -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: Fri, 5 Oct 2018 10:59:36 -0500 > In yam_ioctl(), the concrete ioctl command is firstly copied from the > user-space buffer 'ifr->ifr_data' to 'ioctl_cmd' and checked through the > following switch statement. If the command is not as expected, an error > code EINVAL is returned. In the following execution the buffer > 'ifr->ifr_data' is copied again in the cases of the switch statement to > specific data structures according to what kind of ioctl command is > requested. However, after the second copy, no re-check is enforced on the > newly-copied command. Given that the buffer 'ifr->ifr_data' is in the user > space, a malicious user can race to change the command between the two > copies. This way, the attacker can inject inconsistent data and cause > undefined behavior. > > This patch adds a re-check in each case of the switch statement if there is > a second copy in that case, to re-check whether the command obtained in the > second copy is the same as the one in the first copy. If not, an error code > EINVAL will be returned. > > Signed-off-by: Wenwen Wang Applied, thanks.