Received: by 10.213.65.68 with SMTP id h4csp527218imn; Fri, 16 Mar 2018 10:26:34 -0700 (PDT) X-Google-Smtp-Source: AG47ELuYzDrYQBv7awgRXwT450BI3+TfHnjKW2qJLRnTIvQXVGXYxOPmKmVKFoUytQdRJ+8QCS4H X-Received: by 2002:a17:902:b183:: with SMTP id s3-v6mr2981577plr.108.1521221194836; Fri, 16 Mar 2018 10:26:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521221194; cv=none; d=google.com; s=arc-20160816; b=hXe3SitrE9jbozfjIHxmuaS9AdsDtRdWXYcedKiF6yQepgD205Mj7n3TKwgmTJkmEl s/73ApwryxAbz/OAsFXlDIA44wJbRpZQWhy3L1ZBvkbbFoYdfbFNohA1YJzYwrU7OO99 GUBvv5Ao/bZY+qps1EMuxv8ZjMbIp2UB3ticMgxVvjMA4MPlF47VO2SCo0vTfkNRndAk v2f7bzdl4pTtoI5NQO+sCGpAS67nVfL/tl293lnvmbu9Tz++WEHE7r6MrzlMvEXCw1H/ DmtHo+kqtfsuotYDWleUCAccaZ2FD4F5eO9ehGnUwzg+V4pO/1NSEF+rUec4mKeUzpCv BDhA== 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=VHMZzaxwstEZu9HyG7rRb3SWlk8I6fkedj+UjlIVhw0=; b=Ax005QrZypOIjkQ5HbWJWevmOIFLKqFzYgF6LVvOtVVIFMzmFqLE/9RReFKUeUWeM9 f8beuSMbAV6KE5rssivO3nMpjxW6x9Rb6u1dkpuI3yXKS4DxRGKbpYGDXIyKFg7bGdf4 Leb2L/18mbm6peokGwUChCzPqVXL6Vy2ATpD9aCabWszGoP1OhAg7fFCvVRkvl/DYWH/ Ljb8oseH5xePhvGWdH/kOv7rTEbOM09MqET+gGb3TlbXh1O1in+ko1AdCLnG4yJta5ZY cNuKFylawg9ew0at4CC18eG6eYJca05ITB1vL/BwrMNnw2aKemAV3DHPVtGnDnSIWV+A sAvA== 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 p66si4864781pfk.100.2018.03.16.10.26.20; Fri, 16 Mar 2018 10:26:34 -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 S1753198AbeCPRZR (ORCPT + 99 others); Fri, 16 Mar 2018 13:25:17 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:36014 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932973AbeCPP3D (ORCPT ); Fri, 16 Mar 2018 11:29:03 -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 0BB4DC8A; Fri, 16 Mar 2018 15:29:02 +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.4 56/63] staging: android: ashmem: Fix lockdep issue during llseek Date: Fri, 16 Mar 2018 16:23:28 +0100 Message-Id: <20180316152306.137677684@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180316152259.964532775@linuxfoundation.org> References: <20180316152259.964532775@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.4-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 @@ -330,24 +330,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; }