Received: by 10.213.65.68 with SMTP id h4csp509041imn; Fri, 16 Mar 2018 09:55:15 -0700 (PDT) X-Google-Smtp-Source: AG47ELudJhBjnqLI9OkSUXn1a+1JGuxcrOCcUEtNgW7nEolnEbPsIEd2Vkgz/t88C5NrWVarw5CF X-Received: by 10.99.168.68 with SMTP id i4mr1964837pgp.420.1521219315544; Fri, 16 Mar 2018 09:55:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521219315; cv=none; d=google.com; s=arc-20160816; b=MmNwrnljnWUnLtuwP5oPAjBWT6QASR+sl5YbFsxhVzW2zILCNkyN9g6pXtTgk97OKd 39VDJf6512sAkX/ACMvW1LQT4/XyrDJtanXN+YCuxA6Jj3ViyVJG5LP9n7Ck1gNQ8m45 xf6iI/vvrAzhUixRbQj0in0blUwSd/sbG5ugJE9phbWZlQ1JugoVC3Zf9QgFFHHEQyo9 F4QQZC/lhNvXUIfKr5gQpVhJM0g7zuNbmlGZs9PCrNbSj7Hg83az+j+aT9wic2O5ZBP7 5D7fAvhpjIEZwkHO6ySo4KCNSwWNT2bn+SMSggoqnXylldN4DiosW78UHmfOq9BgpSmw 1/Sw== 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=L4B7BBtK04anuU11IGqX/pOpMl7Aq98v1n/L7N+G38c=; b=UTkoMxpmRjg8QinciULZKOcxv8PfA2uzljTQfMHYaDRr5LkmtgKss1mq8woNVSRwkx y2+yprf9pWHf2lbRqyqEiJeMkJKWbvuRfKT36Ezp1+qnyYPBZa/owbHmQqKNgV+Nrxko +V05FwbxrcFJvWYgTE9TLcaGUC48Jq9mFC418693r6L7UlJ9GySrYOlyacXJaGvNT9bH hf2hN6gtz4WM0BnZkQs0Cx4bx0+gXnGoRm5IMpSYfSnvEwl/GU7kmZjPpb067gHik6DO qjp+/MGerw3+XT+wYsMHxzMszA2RVUttNL1fWnRHJ/AZ6SlGjoAoEc3sVy0vuulPakTD uX/g== 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 t66si5281645pgc.606.2018.03.16.09.55.01; Fri, 16 Mar 2018 09:55:15 -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 S933937AbeCPPeW (ORCPT + 99 others); Fri, 16 Mar 2018 11:34:22 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:39370 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933890AbeCPPeU (ORCPT ); Fri, 16 Mar 2018 11:34:20 -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 917F2CA4; Fri, 16 Mar 2018 15:34:19 +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.14 015/109] staging: android: ashmem: Fix lockdep issue during llseek Date: Fri, 16 Mar 2018 16:22:44 +0100 Message-Id: <20180316152330.774340222@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180316152329.844663293@linuxfoundation.org> References: <20180316152329.844663293@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.14-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 @@ -334,24 +334,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; }