From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC216C25B4E for ; Fri, 20 Jan 2023 09:00:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 40A856B0074; Fri, 20 Jan 2023 04:00:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3BB756B0075; Fri, 20 Jan 2023 04:00:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A9636B0078; Fri, 20 Jan 2023 04:00:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1A6456B0074 for ; Fri, 20 Jan 2023 04:00:20 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D2AC9120B60 for ; Fri, 20 Jan 2023 09:00:19 +0000 (UTC) X-FDA: 80374580958.13.A3285E2 Received: from r3-18.sinamail.sina.com.cn (r3-18.sinamail.sina.com.cn [202.108.3.18]) by imf01.hostedemail.com (Postfix) with ESMTP id 6BE234001E for ; Fri, 20 Jan 2023 09:00:16 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.18 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674205218; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eMMBVgMi5blqZGWXQpjD5Aplm1JJ6zQLjSFn0ECWLjw=; b=AHIzuts1RVXoelQRCByKx369+Uz/j1bUGBrAY0ol3OK6wXeyhPIgisNGo2xPKZRbgZv8N6 KBktfh/WXVbOEJmHA/fLdEevK6SItFSYb3tP5y9gUHra1avrB3QW06G2ocoGDprc9S9CZq Wzm3ARz6gs1QGZcMsmEcHJsen0qr7a4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.18 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674205218; a=rsa-sha256; cv=none; b=y3QPTstYtjHJhIXRa9hiwGbSPptOkmOT3r1OCUsG/z+6S5SY+mcE8SHXJ2BQVYD6XZVJin eqy+zFO8Ivv9KGRsjqU5k9Vtms9+eP0Sm5BeQu/Ljv4KnmMYW5uYItxqVVY1o0yZqk9Lqd 1P3q9XvO4FxNzXaZMIYuGY2MgVRWQc0= Received: from unknown (HELO localhost.localdomain)([114.249.61.130]) by sina.com (172.16.97.35) with ESMTP id 63CA5746000369D3; Fri, 20 Jan 2023 16:56:40 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 7883215079228 From: Hillf Danton To: Suren Baghdasaryan Cc: Munehisa Kamata , Tejun Heo , ebiggers@kernel.org, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mengcc@amazon.com Subject: Re: another use-after-free in ep_remove_wait_queue() Date: Fri, 20 Jan 2023 17:00:01 +0800 Message-Id: <20230120090001.3807-1-hdanton@sina.com> In-Reply-To: References: <20230113022555.2467724-1-kamatam@amazon.com> <20230120013055.3628-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: u868xu41rb8ydmuitjgmixmjofa7prcs X-Rspamd-Queue-Id: 6BE234001E X-HE-Tag: 1674205216-685204 X-HE-Meta: U2FsdGVkX18lUMfikPJQ595zyK1f9bjYO1G4Js9/Vqx7Zh9dzIZvjp9WhEo9fQftlY+f3ioA7y38ZK4koOvPxPm92nceCjJE0GiyG0h1sZNJtEbfgSSjzE+1g5yaOLpc20rIr+y9jFRb/ZVie9KHCC5/7tzjGCwg279OsU0gjHuwf+RqZS+SWvAGlNHn95reY8gkmFkuW2QkP+cTJpRNIE9UoB5kSZmqmzJyi55a+rrH6vVqXSiCLH6Dlr5DUT3RsT2UqNmwvnrEpqqXhKbHi+NbjHGAovKK4GOPr6dB99Hq2JhG1GINbBcdxyDxvOYxtzd0bnWL75MaUDznlvGTbK6plhR7BHhqF1vOhBwusBdMsrOqV12w9DIDVDbkb2TeEDoqho0V83FS4eeXmLG3RghNd9i7HeYK9es4ByVlj9WpooEwUuVsPjiGUS8lvqJPrSVBFVo7oq97Rw5pNESSyqQPGqInM7P/47GTs+IYqVfGCzzn8Kw7lRkJ8+lDxa5dDEo0XkhAnif4kpgJc2SCKQe9z6ayVHtyA2CynMhExh+h/ePdNQpiyajryoRCwy+i7krdvHFvBM7lzlLAEq6QCaifTRimX88ULjvQgzSgpsGJyu2RUf+HpPjFLTFom2YiqgUnXv8c4F+6kb6rPagEsYgn0TDYm+8HvV41QSd/onRhFAXMQb+hfISsDwVl8HGXI65dNHsDFEqsJoQfsMVY/y70KgjPmXvR8Bqn47Myxke3DiZGXIzTOZ7VgodJLy3mfu8FFFRgF9JvXsGIdZUeTrrDkRblw0X3EXCRCmeQk3sxqVX1C2cjI3BsHW1mwaUczBbFKQhkosC+ob1Ox4AYGraGXqoRC3TofdR69vqQHVlcufxGYRRTmYNvQT4pqr2tDQ+7qMrLRgJs5WR4vocUfjN00NxgMwae1X0IR824pBWPU9tmh6qV6fKrYr31/J5P+LJQOnPyhUhEMAChTPS eZwitFqY Mp5+WmM4o7dh8paVavuadoXFpN83lSbZLNk0ZdslMOmppUk0nYzePdJPIxdqMw3k0mjIFm/s5wFrPv893Gre9Qf4D3Z8nqFbKRL1nNscOzoDnSIYJ59rQ8dvhCZG1NZ+/dXxxZibRX9fi17MYuz0MiO5b4aO9yZL9GEy18s+oa+yEU4hB2pZGQeL7XA2whZPFxADdvwmsgRcFkLp7LF0UUqlwJoYdr5rqRI83 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001386, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 19 Jan 2023 17:37:11 -0800 Suren Baghdasaryan wrote: > On Thu, Jan 19, 2023 at 5:31 PM Hillf Danton wrote: > > On Thu, 19 Jan 2023 13:01:42 -0800 Suren Baghdasaryan wrote: > > > > > > Hi Folks, > > > I spent some more time digging into the details and this is what's > > > happening. When we call rmdir to delete the cgroup with the pressure > > > file being epoll'ed, roughly the following call chain happens in the > > > context of the shell process: > > > > > > do_rmdir > > > cgroup_rmdir > > > kernfs_drain_open_files > > > cgroup_file_release > > > cgroup_pressure_release > > > psi_trigger_destroy > > > > > > Later on in the context of our reproducer, the last fput() is called > > > causing wait queue removal: > > > > > > fput > > > ep_eventpoll_release > > > ep_free > > > ep_remove_wait_queue > > > remove_wait_queue > > > > > > By this time psi_trigger_destroy() already destroyed the trigger's > > > waitqueue head and we hit UAF. > > > I think the conceptual problem here (or maybe that's by design?) is > > > that cgroup_file_release() is not really tied to the file's real > > > lifetime (when the last fput() is issued). Otherwise fput() would call > > > eventpoll_release() before f_op->release() and the order would be fine > > > (we would remove the wait queue first in eventpoll_release() and then > > > f_op->release() would cause trigger's destruction). > > > > eventpoll_release > > eventpoll_release_file > > ep_remove > > ep_unregister_pollwait > > ep_remove_wait_queue > > > > Yes but fput() calls eventpoll_release() *before* f_op->release(), so > waitqueue_head would be removed before trigger destruction. Then check if file is polled before destroying trigger. +++ b/kernel/sched/psi.c @@ -1529,6 +1529,7 @@ static int psi_fop_release(struct inode { struct seq_file *seq = file->private_data; + eventpoll_release_file(file); psi_trigger_destroy(seq->private); return single_release(inode, file); }