Re: another use-after-free in ep_remove_wait_queue()

[Hillf Danton <hdanton@sina.com>]

On Fri, 20 Jan 2023 08:28:25 -0800 Suren Baghdasaryan <surenb@google.com>
> On Fri, Jan 20, 2023 at 1:00 AM Hillf Danton <hdanton@sina.com> wrote:
> > +++ 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.

The epmutex serializes eventpoll_release_file() and ep_free(). And this
is in psi_fop_release(), so no chance is likely left for another release.

> 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.

Good point but cgroup and kernfs have no idea of psi trigger.

The bonus of the uaf is check polled file upon release in scenarios like
the psi trigger.