Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp342245imu; Thu, 3 Jan 2019 21:37:14 -0800 (PST) X-Google-Smtp-Source: ALg8bN5rDOiZrDlCzrZ4Y8oUOOk2fx/vzvhyGUE3uQq13TUZmWZ1geOVrCXr0rXKelaoL461/zCn X-Received: by 2002:a63:9256:: with SMTP id s22mr46234877pgn.224.1546580234172; Thu, 03 Jan 2019 21:37:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546580234; cv=none; d=google.com; s=arc-20160816; b=KvXQT+OKgH9ZvSCTqWhxRMeUpfVoJ8fKRLF8gpvnPfYUdLFSwe8xuQzYJGek7DH4Pu 5y5s+0SiZQlh+i2EgLko7kPVT3TLlsdMtgFg0oEWvyC2WkR8p6hP88abeTlWlwhL+Vb4 FksPEGxicVSUL+W07mt+11FZW+RFDv1SIw0vihXPifbl7hCPaIyYqoBwkfETYiR2taQR IlPpFm1dG6bClLeOovxSiRK4f9O9oqoLdsGwg6IoE3+ZAvwxHOffdzba7cYPUnl54Uix NaEVDNYARdfwO8WQkmy/5JFOWdclwaxhkiwgTlkP5oB/b51wzzce7u+lKh7Be7ymLh3N d5OQ== 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 :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=DuVpdqjVdMXlTc4oGOoodz9he7e9kbdBw5/WGbFi2wI=; b=Y/lgFKQWWuOhOdFb7K95xxtZuzGMy5mrwXnxsAIeZQIuYplJXakgtin0k/zZAUQXwa woaDf+3THRWanAwd+1ekkX3B/RVJNYMn6nBd3lEYqBa5cO+hfrwdApktxETWgNY/c9Po QnCAFrFWo+2QXJSBhobcbO00eAe/kdNXTS68ar5D6h2n6gFpzV3/h8mDAbbgSIRmU1XH nWbz+xTaf1QnA+C1ef19re8FZkNm5JW3HewNrFA3Kaz4XnTYgmiBRgOtCcPYY3HPN1Sk JCzknb1XqQSaqlV5MUQ1EDZ2JLaR5lIzB36lmBH8DF4Df/r93+D/7Ds3dw5MxzRtDNHJ wmVQ== 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 a19si29228240pgj.429.2019.01.03.21.36.58; Thu, 03 Jan 2019 21:37:14 -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 S1727032AbfADAsC (ORCPT + 99 others); Thu, 3 Jan 2019 19:48:02 -0500 Received: from gate.crashing.org ([63.228.1.57]:58433 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726003AbfADAsB (ORCPT ); Thu, 3 Jan 2019 19:48:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x040ldeW028655; Thu, 3 Jan 2019 18:47:40 -0600 Message-ID: <0adee96b58a533bc8c5927039e96b5ed77c9bbad.camel@kernel.crashing.org> Subject: Re: [PATCH] fsi:fsi-sbefifo: Fix possible concurrency use-after-free bugs in sbefifo_user_release From: Benjamin Herrenschmidt To: Jia-Ju Bai , dhowells@redhat.com, joel@jms.id.au, eajames@linux.vnet.ibm.com, andrew@aj.id.au Cc: linux-kernel@vger.kernel.org Date: Fri, 04 Jan 2019 11:47:38 +1100 In-Reply-To: <20181226135618.12784-1-baijiaju1990@gmail.com> References: <20181226135618.12784-1-baijiaju1990@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.3 (3.30.3-1.fc29) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-12-26 at 21:56 +0800, Jia-Ju Bai wrote: > In drivers/fsi/fsi-sbefifo.c, the functions sbefifo_user_release(), > sbefifo_user_read() and sbefifo_user_write() may be concurrently executed. So after refreshing my mind, looking at the code and talking with Al, I really dont' see what race you are trying to fix here. read/write should never be concurrent with release for a given file and the stuff we are protecting here is local to the file instance. Do you have an actual problem you observed ? Cheers, Ben. > sbefifo_user_release() > sbefifo_release_command() > vfree(user->pending_cmd); > > sbefifo_user_read() > mutex_lock(); > rc = __sbefifo_submit(sbefifo, user->pending_cmd, ...); > > sbefifo_user_write() > mutex_lock(); > user->pending_cmd = user->cmd_page; > user->pending_cmd = vmalloc(len); > > Thus, possible concurrency use-after-free bugs may occur in > sbefifo_user_release(). > > To fix these bugs, the calls to mutex_lock() and mutex_unlock() are > added in sbefifo_user_release(). > > > Signed-off-by: Jia-Ju Bai > --- > drivers/fsi/fsi-sbefifo.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/fsi/fsi-sbefifo.c b/drivers/fsi/fsi-sbefifo.c > index d92f5b87c251..e278a9014b8f 100644 > --- a/drivers/fsi/fsi-sbefifo.c > +++ b/drivers/fsi/fsi-sbefifo.c > @@ -900,8 +900,10 @@ static int sbefifo_user_release(struct inode *inode, struct file *file) > if (!user) > return -EINVAL; > > + mutex_lock(&user->file_lock); > sbefifo_release_command(user); > free_page((unsigned long)user->cmd_page); > + mutex_unlock(&user->file_lock); > kfree(user); > > return 0;