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 2C7E4C25B4E for ; Fri, 20 Jan 2023 16:28:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B94136B00A0; Fri, 20 Jan 2023 11:28:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B1CC16B00A3; Fri, 20 Jan 2023 11:28:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D5036B00A4; Fri, 20 Jan 2023 11:28:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 73DF86B00A0 for ; Fri, 20 Jan 2023 11:28:40 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 524B41C672A for ; Fri, 20 Jan 2023 16:28:40 +0000 (UTC) X-FDA: 80375710800.26.6205AF7 Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf05.hostedemail.com (Postfix) with ESMTP id 2EE68100008 for ; Fri, 20 Jan 2023 16:28:36 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UWgCAbzs; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674232117; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UsgwD1M2WCaGKZ28mz2lre3YTN/XGgKTUhmzvANIwrs=; b=7cSIXdgXMgJqGoJBLcwxNPGAsMqTWzr0DYTMDEmJ4rc+GjwtDf93tYXUj/d1pUJFrqP2wi pQ+I1mAsx+bDA7eNuVBHqw9FxT8w3eswTkQ5ICILV8BTyhNvyo2SXnwqubFCXSISTAxyep HOGjBZ5UzWsg0hboS8s2tDUOp4UhwUc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UWgCAbzs; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674232117; a=rsa-sha256; cv=none; b=nbKx1emnyfOzmKaQ78ebWJI3w+E7CVHammtgKsvuSdviBr44o2RIEy/tKxn8J9Xn5TXiXi 79/9BWb+Js6zL78o9JGuNnaLUvmOx+jQ9n5seZ9/0CShJrisQE2Dhhv2UzBzEJ8sg1NnEN +xf/vYXFHjkC3wTAy7avMk6wTDDRalM= Received: by mail-yb1-f170.google.com with SMTP id c124so7307924ybb.13 for ; Fri, 20 Jan 2023 08:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UsgwD1M2WCaGKZ28mz2lre3YTN/XGgKTUhmzvANIwrs=; b=UWgCAbzsC3BkBkDEqEdU8jLnBSczGtgp4NjRW6kn+6R2j3opMeudfAuaqqqMFkgHMN Z9P5B9yuyMwdGPkgRNgnz/TOfWo4Wt5uUNjhZ9I83OZjL9gygtUTM8AtpJylYaZz4T75 llL+lsUaE67/CZ536Vs50o4WQOxUgeiSOOc2utQEH0qXqFdF+cnrQO8WfbOxo72M94IP EpLffVj4j9OiAUW1gjBCCgOnTUNBiCRg+9C5Ji2JKF0CUrBWHcpBBMDgAm5WTkUeKzl5 8Iq3R9Gt3UyVNdl2fwcUJN8gE7Zx9keZ2uWloUQNxAYituoqb67QgwmozacBZS8hJrOt R4pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UsgwD1M2WCaGKZ28mz2lre3YTN/XGgKTUhmzvANIwrs=; b=iVIXYQnzFdWIRbtMqrTFrJqTLv19aYW324GO54KQsRg287KzhNJz6p+zbej9U5YW+W uK9MThwah/5Zvvl/FZAELBWIV7Pp9+yUao+LQpgQUgDTSBp5khjSqIyxJbsId32qWgCq C1NxTebAGaOqteh3MqZYbL1uvhbsin0rqTIRyiZKc18D3o4cHLP+jdQnic1JvzJUT2Bx ibJfR2Ql+7gVCPmW1b2zEOS/BWBdOnG411Dfh7AtDbBjrGYvXwUQ1mJSw7GKMTAfjNry 98KDCScmFyeHtoO7OUJV0R8wVhUqUskE3BgGzQGz7G3aU9hqsEqyGLfH4YpJ2ph8bLaT eCzg== X-Gm-Message-State: AFqh2koTw+rrCtBtxCrejLeZJvWHxugez3jIt5IfI3cOTnsrt/NmbS4b inTAEAvT6dqorp28LulEhat6o3AK+W78RPzyA3XAFu9TsRQCmWi6ydE= X-Google-Smtp-Source: AMrXdXsoVM0i9/+nWuevD8gu1lstoic8Y7elrHX1HRwzV169/ExhmAVo5mtJCbkcuPTncHwqD6EZnANKYQfFrTvFbjI= X-Received: by 2002:a25:ceca:0:b0:7e4:115c:9cf6 with SMTP id x193-20020a25ceca000000b007e4115c9cf6mr1790830ybe.316.1674232116013; Fri, 20 Jan 2023 08:28:36 -0800 (PST) MIME-Version: 1.0 References: <20230113022555.2467724-1-kamatam@amazon.com> <20230120013055.3628-1-hdanton@sina.com> <20230120090001.3807-1-hdanton@sina.com> In-Reply-To: <20230120090001.3807-1-hdanton@sina.com> From: Suren Baghdasaryan Date: Fri, 20 Jan 2023 08:28:25 -0800 Message-ID: Subject: Re: another use-after-free in ep_remove_wait_queue() To: Hillf Danton Cc: Munehisa Kamata , Tejun Heo , ebiggers@kernel.org, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mengcc@amazon.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 2EE68100008 X-Stat-Signature: auw6zurradp8z31krc5n6f3cftre81d9 X-HE-Tag: 1674232116-748029 X-HE-Meta: U2FsdGVkX1/S3jZcwW++t9yP1NlZfPrk6l8+s0S1sLow2T5cwifzL+2ATaHl+TUIr5ySVvE3unZ5QazkW5Uqb9xulUplsOkEW6jmU33vsbIqvUCdkXvNK3zoFO2PJlubSN17DddhNuP8qvkgJlx4H8aBumh1KH9NIAPx/gw9Kf/8m9ouoVXHwCIWPjmP9lzcbVHX04/qE2554MeZnhevhhmCZjIjpMhUnOxXq+m4y4TAH/Mr9Uvfk629fX8NghLx6EqoL74w3XKmDuIEJIuJ4siedoUsYV9DdMMDObUDsmfoQO4KQ3WrZuIcVmB6nmUysIgesgYo10PemDtu2sIId6ZcjvEjxM4hLNisaFTck5w1MTF+dmyDxbqpm+GRDfTXaAgm4SqemnWjvgPo+gUbfsAUlJ7M511akfIQ+j+5K2m5Xnd3LcbvxAjFvWMqg0p9Hqc4axNEcN7aWcKEGSseF2EWq1GfNAFx3iCM6gBE+UYX6Zpi4A+0IEOBCq2jU0pI4JPv7WZ4U2GSsBn9oksqheSn8pegzki3NOXkbGgSGDu+wE2gqb69KIntnBhyhga3gKm8a1tBxYE0+IvcwVFODKV1t7FmrJINVwhld8hIn/tEQ6eTG5L/gKdUUvDwZB2UBWF7/O6pMlA6AbURmN3+zv+mF5nLPdaytROHBzaZmTo++Gaa8X1A3M/PTwCb0oRRImUF9RIvEFOcidhtzwYdRm7Wefg8d2PRBv6EL4THRZVuEFjkXPPwabVvZJ0Li27kSFNRf6by8To/IFmmwJ+8hLmg3EchVhczCR3WrJz+MGhqhwCajnm6BhUbO/cuv7zAUp8XygGZstELe+PfMaeEy4WnIhAtjsbwXldEoUyayKaC3Lm84ZbRkq+Z7bv+FQ80ZKYEPw4VZbL4hizHKrRMKiGjP7TfzyNpFNVIBR4T3ftR3sOzKo+1ma/vhBAM4ZLFu1hjEwnpiIrNszwfKgo ggsiryfN GyOdeSh3DIgY8/avYPXW/bHzCp9e+1dTHGQf/3yLfurRV9zhuHRZBU/5cOfL7+rIrEsQlQqkrE64HXDn22ygl+HhFA269GKnRSn8FaOVlnKdcMcwFzCaWTnibhmBEO5/3xdzzuUJCJ5ErNT63zssKBWCQjJZepgzw5jZLY+fAMdFJ3i5sjQH8gM+OqoyKuwaPWy4rf8lzRDVYPb1/yDhK1bjRX848NRxD+pgU4ugFiy3hMg8lATvQtaYAKpYx3NFhSmO2dZMTG5AJVJpgbGVr63iyafaa87KGQjaVW+nIU1WF8kdaSRUG3s0jys9Fu3b16XqI+NP7VR37DHhgn9UZL9oUAN+ZfCp4jl3eMu6pDvGbU+MdTqK6HEB6uf9JCEUdKbvlwQEof9WVBolWq751xQ4Kt/iaoxqH3Huo0XVaK+AVNSA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jan 20, 2023 at 1:00 AM Hillf Danton wrote: > > 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); Be careful here and see the comment in https://elixir.bootlin.com/linux/latest/source/fs/eventpoll.c#L912. eventpoll_release_file() assumes that the last fput() was called and nobody other than ep_free() will race with us. So, this will not be that simple. Besides if we really need to fix the order here, the fix should be somewhere at the level of cgroup_file_release() or even kernfs to work for other similar situations. > psi_trigger_destroy(seq->private); > return single_release(inode, file); > } >