Received: by 10.213.65.68 with SMTP id h4csp511105imn; Fri, 16 Mar 2018 09:59:40 -0700 (PDT) X-Google-Smtp-Source: AG47ELseN+lrmBUoEwOkVJUb9xJFVP3/q64GQJ8RW3k/zHA3H3Jzbqkwnnvn+5l4tvP1qF78sZQv X-Received: by 2002:a17:902:107:: with SMTP id 7-v6mr2879779plb.374.1521219580737; Fri, 16 Mar 2018 09:59:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521219580; cv=none; d=google.com; s=arc-20160816; b=ras+yzd1yb84oH+OhMyvCX5zzmfer8gpeD0sOdBNihQCBOyypN023OCTrrlltfQ3fq SIBU9R5RVscfHePRlOM8ghYaz35mosDvxNou9f0hH6C8N+I9pejFi9giYKNm44gl+v/0 4UTyjZJ4VbC7O+6cCXg+KcSAMGMn2sKzNi91GlYQWAM3moYnA8rHwolDKYefj9uv0OI4 thxvgaSIfT7nXwA+7b9vf1iiFbb2uhgKWuYryRifSRx7fB9mWASJeFNDdqCJVgoezEBc hN1czmlMoB9yn1AkUmTAlQABtdUG+Ai9P1fYL+F9a9D87nCU7Hp+q3ETN1BMIwF7Iau5 YvCA== 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:message-id:date:subject:cc:to:from :arc-authentication-results; bh=DkMU/MJssNdUH9achRTh+JRCSV6K96zVa7NM3bmuN9c=; b=OWmJZQgrpkNFqVVm2Yy7UySB9YtVwzsmkKHozFcciqSTVZpLlK4Ym6v92qOFnVyGxG CDGXnH+GunZT76xuRv1dWRw7VEh01gSWoWzzsqrOucTI944KgBq7i4xghjujcBJUnzNE Idvn72ngI5py7roYF9MyiqgkE3LIBELEaTEZI1iVhAagtI+99wwVPSCaglJdARorwFte pso6NjKqLfbd2oBUFjolcBAmqyWPV8j/L8JwgsTl5By1cgj2DhrvS5d0mwP3KbYajfcA PS/gy4vMYLwtRv2cwuSgK38m79ET6FgI1ndQAjaafQPAJ1eWAV7xF+cQmf7gy+b+XzME /PDw== 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 q11si5193906pgv.144.2018.03.16.09.59.26; Fri, 16 Mar 2018 09:59: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 S933729AbeCPPdR (ORCPT + 99 others); Fri, 16 Mar 2018 11:33:17 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:38354 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933234AbeCPPdP (ORCPT ); Fri, 16 Mar 2018 11:33:15 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 862551255; Fri, 16 Mar 2018 15:33:14 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Todd Kjos , Arve Hjonnevag , syzbot+8ec30bb7bf1a981a2012@syzkaller.appspotmail.com, Joel Fernandes , Greg Hackmann Subject: [PATCH 4.9 77/86] staging: android: ashmem: Fix lockdep issue during llseek Date: Fri, 16 Mar 2018 16:23:40 +0100 Message-Id: <20180316152322.517787927@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180316152317.167709497@linuxfoundation.org> References: <20180316152317.167709497@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Joel Fernandes commit cb57469c9573f6018cd1302953dd45d6e05aba7b upstream. ashmem_mutex create a chain of dependencies like so: (1) mmap syscall -> mmap_sem -> (acquired) ashmem_mmap ashmem_mutex (try to acquire) (block) (2) llseek syscall -> ashmem_llseek -> ashmem_mutex -> (acquired) inode_lock -> inode->i_rwsem (try to acquire) (block) (3) getdents -> iterate_dir -> inode_lock -> inode->i_rwsem (acquired) copy_to_user -> mmap_sem (try to acquire) There is a lock ordering created between mmap_sem and inode->i_rwsem causing a lockdep splat [2] during a syzcaller test, this patch fixes the issue by unlocking the mutex earlier. Functionally that's Ok since we don't need to protect vfs_llseek. [1] https://patchwork.kernel.org/patch/10185031/ [2] https://lkml.org/lkml/2018/1/10/48 Acked-by: Todd Kjos Cc: Arve Hjonnevag Cc: stable@vger.kernel.org Reported-by: syzbot+8ec30bb7bf1a981a2012@syzkaller.appspotmail.com Signed-off-by: Joel Fernandes Acked-by: Greg Hackmann Signed-off-by: Greg Kroah-Hartman --- drivers/staging/android/ashmem.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -343,24 +343,23 @@ static loff_t ashmem_llseek(struct file mutex_lock(&ashmem_mutex); if (asma->size == 0) { - ret = -EINVAL; - goto out; + mutex_unlock(&ashmem_mutex); + return -EINVAL; } if (!asma->file) { - ret = -EBADF; - goto out; + mutex_unlock(&ashmem_mutex); + return -EBADF; } + mutex_unlock(&ashmem_mutex); + ret = vfs_llseek(asma->file, offset, origin); if (ret < 0) - goto out; + return ret; /** Copy f_pos from backing file, since f_ops->llseek() sets it */ file->f_pos = asma->file->f_pos; - -out: - mutex_unlock(&ashmem_mutex); return ret; }