Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAJuCfpEMEsSYcKakFiDK=QV+apW-2baLcUcw7uRyrmKkWVnR8A@mail.gmail.com>
 <20230113022555.2467724-1-kamatam@amazon.com> <CAJuCfpEH7kC=S8S_SRLW-X483kpaL4xdn5b35Ou08V7b56QdJA@mail.gmail.com>
 <CAJuCfpHV2-pnHd6U3paA1fO2gaYP1RTqAJwp_5QC7C2YR3JG5g@mail.gmail.com>
 <CAJuCfpFZ3B4530TgsSHqp5F_gwfrDujwRYewKReJru==MdEHQg@mail.gmail.com>
 <20230120013055.3628-1-hdanton@sina.com> <CAJuCfpF9tCx4mjYFyX+p7qO9qt+rm=UMSdBt-uzaOqE0ThG04g@mail.gmail.com>
 <20230120090001.3807-1-hdanton@sina.com>
In-Reply-To: <20230120090001.3807-1-hdanton@sina.com>
From:   Suren Baghdasaryan <surenb@google.com>
Date:   Fri, 20 Jan 2023 08:28:25 -0800
Message-ID: <CAJuCfpFShuXs_CcfXR6PjYyXemapbuHPG0oZQJb_Y9ZpCUGZXg@mail.gmail.com>
Subject: Re: another use-after-free in ep_remove_wait_queue()
To:     Hillf Danton <hdanton@sina.com>
Cc:     Munehisa Kamata <kamatam@amazon.com>, Tejun Heo <tj@kernel.org>,
        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"
Precedence: bulk

On Fri, Jan 20, 2023 at 1:00 AM Hillf Danton <hdanton@sina.com> wrote:
>
> On Thu, 19 Jan 2023 17:37:11 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> > On Thu, Jan 19, 2023 at 5:31 PM Hillf Danton <hdanton@sina.com> wrote:
> > > On Thu, 19 Jan 2023 13:01:42 -0800 Suren Baghdasaryan <surenb@google.com> 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);
>  }
>