Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2925848imm; Sun, 13 May 2018 00:08:40 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoqrRa2UUKvSUONPC1WnXWh9NSbtqmOzZ1bpu6WRl8aMCHwzGLp+PCAmigIH/UHC0/K+p6F X-Received: by 2002:a62:7105:: with SMTP id m5-v6mr5504047pfc.167.1526195320598; Sun, 13 May 2018 00:08:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526195320; cv=none; d=google.com; s=arc-20160816; b=CeACrqJONhr0xwVc5y1xCsPLKHq0bPzYH915sTzwJdVEBM3x74gZ8RUoBUZLs5HuKG YMcrMBZzv5SS/ehmc3IyNGKLn9EeqJm0f8sRd4fGJyVIkKdH21SCTNHLxB+Wend9G/3k 6yX/PT46CEJFWdAr5GFXFmf3joMjEkm+r0vJIrg5NJY2Gt2m/3C/SW8dvD6XDx74pyec VQ41X650zsDXW0n5PTuQaKvr8tVV5v61yA/nfGdDrle9EMR3lK7xC1Z1EcBfjvDgsymO uwDxpxz2zE1VUmAr2JJP7A6CVsHfZMHcAtcnS1WVg4pjzJ5vRTwPcKa2DpULy3cUBVIW tV+g== 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:subject:cc:to:from:message-id:date :arc-authentication-results; bh=U6Y9QptViuqKcOMDjfsq6bEKdHS/rzXckig+m/BRNfI=; b=HsYGzGp4oXW0LTOdlmK+dZbNhgWHEUBYptZlNuK7+ajuT6wtXAmF7LFBLVPYqmqEVQ +1NjBY2gJTvFAQ8nTrSWAZWX+PlqEwCCxmWN1ARBPD/rgeiHe5B9S52w/iUa5DpKxS3T IuEn8yoEoKKTS5ciATT5LC52T/8A99TNf+6b6kw2Q9Em/KXgDMCxo71z/2uTgRojjcBX EAgOr05T5mFywzRIF1xrKvFoj/v3QX/MThOGa1w6/YkOIgfigzvlcgZZvD3LDRFaSwwY C5NiziCpakQz5/4Bb+/qVU4Wnobt2QKt3WekfGvkuPffJTgRwRy/+eUEeWRW0U/HcnqG OWLA== 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 t9-v6si7139631pfk.228.2018.05.13.00.08.25; Sun, 13 May 2018 00:08:40 -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 S1751375AbeEMHG3 (ORCPT + 99 others); Sun, 13 May 2018 03:06:29 -0400 Received: from mx2.suse.de ([195.135.220.15]:40941 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751264AbeEMHG2 (ORCPT ); Sun, 13 May 2018 03:06:28 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8C5CDAB40; Sun, 13 May 2018 07:06:27 +0000 (UTC) Date: Sun, 13 May 2018 09:06:26 +0200 Message-ID: From: Takashi Iwai To: "Wenwen Wang" Cc: "moderated list:SOUND" , "Jaroslav Kysela" , "Kangjie Lu" , "open list" Subject: Re: [PATCH] ALSA: control: fix a redundant-copy issue In-Reply-To: <1525545485-12183-1-git-send-email-wang6495@umn.edu> References: <1525545485-12183-1-git-send-email-wang6495@umn.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 05 May 2018 20:38:03 +0200, Wenwen Wang wrote: > > In snd_ctl_elem_add_compat(), the fields of the struct 'data' need to be > copied from the corresponding fields of the struct 'data32' in userspace. > This is achieved by invoking copy_from_user() and get_user() functions. The > problem here is that the 'type' field is copied twice. One is by > copy_from_user() and one is by get_user(). Given that the 'type' field is > not used between the two copies, the second copy is *completely* redundant > and should be removed for better performance and cleanup. Also, these two > copies can cause inconsistent data: as the struct 'data32' resides in > userspace and a malicious userspace process can race to change the 'type' > field between the two copies to cause inconsistent data. Depending on how > the data is used in the future, such an inconsistency may cause potential > security risks. > > For above reasons, we should take out the second copy. > > Signed-off-by: Wenwen Wang Applied now, thanks. Takashi