From patchwork Fri Jun 19 14:32:10 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 223659 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EE6FC433E0 for ; Fri, 19 Jun 2020 16:47:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6BFE0206B7 for ; Fri, 19 Jun 2020 16:47:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592585269; bh=F32g8YyTxc+h/frpxGIHoJ+5HtmH+lMD8vj0E1M3+VA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=qHliJiFFKj6QHb8bz5dse6/wTcJjhFnEspCXlIJkC5af6vvJTiijxqiwiVwli4WgD CxmqkHU8YevWVqrqGHTz2UrF848Da5WlAqJ14k4zXFFNmGc4oapnFP7Ou6C800w8D9 vebNpCw+nEAdzoIqZjStq/LRdOeKsuq588/k4Uqs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393611AbgFSQrs (ORCPT ); Fri, 19 Jun 2020 12:47:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:59106 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388196AbgFSOk4 (ORCPT ); Fri, 19 Jun 2020 10:40:56 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7A010208B8; Fri, 19 Jun 2020 14:40:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592577655; bh=F32g8YyTxc+h/frpxGIHoJ+5HtmH+lMD8vj0E1M3+VA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=neCFEXLEB3QQNBSkMPFbVbttbuVxtsyIq/uoW6TjoCwkCl7F85YOiUADGws5vu3L0 CC5EObVY1klpHITkV2oA/AxFWBzrWYoS5Ct974tJMCbUc6DTWvY9VAxE98Jq3lPjim eUOU6mMuI6P0l3jTIVb+fpwdr4K5rlavmUI53UQs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+7d2debdcdb3cb93c1e5e@syzkaller.appspotmail.com, "Eric W. Biederman" Subject: [PATCH 4.9 036/128] proc: Use new_inode not new_inode_pseudo Date: Fri, 19 Jun 2020 16:32:10 +0200 Message-Id: <20200619141622.106634403@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200619141620.148019466@linuxfoundation.org> References: <20200619141620.148019466@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Eric W. Biederman commit ef1548adada51a2f32ed7faef50aa465e1b4c5da upstream. Recently syzbot reported that unmounting proc when there is an ongoing inotify watch on the root directory of proc could result in a use after free when the watch is removed after the unmount of proc when the watcher exits. Commit 69879c01a0c3 ("proc: Remove the now unnecessary internal mount of proc") made it easier to unmount proc and allowed syzbot to see the problem, but looking at the code it has been around for a long time. Looking at the code the fsnotify watch should have been removed by fsnotify_sb_delete in generic_shutdown_super. Unfortunately the inode was allocated with new_inode_pseudo instead of new_inode so the inode was not on the sb->s_inodes list. Which prevented fsnotify_unmount_inodes from finding the inode and removing the watch as well as made it so the "VFS: Busy inodes after unmount" warning could not find the inodes to warn about them. Make all of the inodes in proc visible to generic_shutdown_super, and fsnotify_sb_delete by using new_inode instead of new_inode_pseudo. The only functional difference is that new_inode places the inodes on the sb->s_inodes list. I wrote a small test program and I can verify that without changes it can trigger this issue, and by replacing new_inode_pseudo with new_inode the issues goes away. Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/000000000000d788c905a7dfa3f4@google.com Reported-by: syzbot+7d2debdcdb3cb93c1e5e@syzkaller.appspotmail.com Fixes: 0097875bd415 ("proc: Implement /proc/thread-self to point at the directory of the current thread") Fixes: 021ada7dff22 ("procfs: switch /proc/self away from proc_dir_entry") Fixes: 51f0885e5415 ("vfs,proc: guarantee unique inodes in /proc") Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman --- fs/proc/inode.c | 2 +- fs/proc/self.c | 2 +- fs/proc/thread_self.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) --- a/fs/proc/inode.c +++ b/fs/proc/inode.c @@ -417,7 +417,7 @@ const struct inode_operations proc_link_ struct inode *proc_get_inode(struct super_block *sb, struct proc_dir_entry *de) { - struct inode *inode = new_inode_pseudo(sb); + struct inode *inode = new_inode(sb); if (inode) { inode->i_ino = de->low_ino; --- a/fs/proc/self.c +++ b/fs/proc/self.c @@ -53,7 +53,7 @@ int proc_setup_self(struct super_block * inode_lock(root_inode); self = d_alloc_name(s->s_root, "self"); if (self) { - struct inode *inode = new_inode_pseudo(s); + struct inode *inode = new_inode(s); if (inode) { inode->i_ino = self_inum; inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); --- a/fs/proc/thread_self.c +++ b/fs/proc/thread_self.c @@ -55,7 +55,7 @@ int proc_setup_thread_self(struct super_ inode_lock(root_inode); thread_self = d_alloc_name(s->s_root, "thread-self"); if (thread_self) { - struct inode *inode = new_inode_pseudo(s); + struct inode *inode = new_inode(s); if (inode) { inode->i_ino = thread_self_inum; inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode);