Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3297297ybl; Sun, 8 Dec 2019 11:50:11 -0800 (PST) X-Google-Smtp-Source: APXvYqwFrpRxKbEReTkAT+bJDNd0pnwNFzVw11DlGCmrDGAKTijdeihBS4KM+E1GltanJqj1Pc+b X-Received: by 2002:a9d:61c4:: with SMTP id h4mr19781563otk.310.1575834611636; Sun, 08 Dec 2019 11:50:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575834611; cv=none; d=google.com; s=arc-20160816; b=C89Xyrw7wlRLBKOp3STiXtTJcqwxyL19+MK5GC83ph4EI4jjG0A3ySHr/YeISLAbQI FMGiYEf9wfwx9Cu4g8r4sBtu1FC7uYiN69aPDutSV6BUiX5d5U9DH6Ozjj6qa8IVwQdN TXcNMFghwnSWYn3LiJXZSNaZKpuiLzGpqzuqABeIz4CHd4UOP3QRuObEtpOps0cFJXVx aBkl5oO4NwM0d/LiZ0bKd8LMUNs2s6EnDkAS9wzibYJTq0FHNddAWBslBMkvQWd1hUCf rZoJu12R4bSFbNCg9uRKRK0Ruze591zI9I/FEQMj+fCXHHo+erdVeByhrzkCIqSVECL9 T7zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=3ZznH21IOOqSDMP7O8jllAZLd69AnrDM8AYtNWjHmck=; b=w1aUyqbHGvzrDHbAMgL8KgkmswD2DagqsH3/HuOsp+Mls0AeWSsrlej+0UQ1bXCQQF wbRK4OWgNouZ6coBJKVRTtB6Q7IZxC7wUeMZmxlITnzS8AqQkQcUMzllqI2lYQ/3vkm2 30GvJZvl3w/ZvF9bFuGJOSr/k7+fKnyreCrAHcwR/oE+KOS1YGsG33rABAjIkwbrPpLZ 13tuInGzHSherNrTDteQzzmpJo2EcZHO/eMX5/JHM7sLAoG0e5NDbyBxNZjCNk3BhOOn oJfaelJXKrvo2W1b1srEcgnAOJDhVY5REQOWUk613dm5b9CZ6P0WX9d2jsTSD+BKIJ0d b7aA== 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 v49si3753527otb.253.2019.12.08.11.49.58; Sun, 08 Dec 2019 11:50:11 -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 S1726661AbfLHTtK (ORCPT + 99 others); Sun, 8 Dec 2019 14:49:10 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:39132 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726506AbfLHTtK (ORCPT ); Sun, 8 Dec 2019 14:49:10 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1ie2YF-0007uU-I4; Sun, 08 Dec 2019 19:49:07 +0000 Date: Sun, 8 Dec 2019 19:49:07 +0000 From: Al Viro To: Vladis Dronov Cc: Richard Cochran , linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fs: fix use-after-free in __fput() when a chardev is removed but a file is still open Message-ID: <20191208194907.GW4203@ZenIV.linux.org.uk> References: <20191125125342.6189-1-vdronov@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191125125342.6189-1-vdronov@redhat.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 25, 2019 at 01:53:42PM +0100, Vladis Dronov wrote: > In a case when a chardev file (like /dev/ptp0) is open but an underlying > device is removed, closing this file leads to a use-after-free. This > reproduces easily in a KVM virtual machine: > > # cat openptp0.c > int main() { ... fp = fopen("/dev/ptp0", "r"); ... sleep(10); } > static void __fput(struct file *file) > { ... > if (file->f_op->release) > file->f_op->release(inode, file); <<< cdev is kfree'd here > if (unlikely(S_ISCHR(inode->i_mode) && inode->i_cdev != NULL && > !(mode & FMODE_PATH))) { > cdev_put(inode->i_cdev); <<< cdev fields are accessed here > > because of: > > __fput() > posix_clock_release() > kref_put(&clk->kref, delete_clock) <<< the last reference > delete_clock() > delete_ptp_clock() > kfree(ptp) <<< cdev is embedded in ptp > cdev_put > module_put(p->owner) <<< *p is kfree'd > > The fix is to call cdev_put() before file->f_op->release(). This fix the > class of bugs when a chardev device is removed when its file is open, for > example: And what's to prevent rmmod coming and freeing ->release code right as you are executing it?