From: Eric Biggers <ebiggers@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Benjamin LaHaise <bcrl@kvack.org>,
linux-aio@kvack.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ramji Jiyani <ramjiyani@google.com>,
Christoph Hellwig <hch@lst.de>, Oleg Nesterov <oleg@redhat.com>,
Jens Axboe <axboe@kernel.dk>, stable <stable@vger.kernel.org>
Subject: Re: [PATCH 2/2] aio: fix use-after-free due to missing POLLFREE handling
Date: Mon, 6 Dec 2021 11:54:00 -0800 [thread overview]
Message-ID: <Ya5qWLLv3i4szS4N@gmail.com> (raw)
In-Reply-To: <CAHk-=wgJ+6qgbB+WCDosxOgDp34ybncUwPJ5Evo8gcXptfzF+Q@mail.gmail.com>
On Mon, Dec 06, 2021 at 11:28:13AM -0800, Linus Torvalds wrote:
> On Fri, Dec 3, 2021 at 4:23 PM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > require another solution. This solution is for the queue to be cleared
> > before it is freed, using 'wake_up_poll(wq, EPOLLHUP | POLLFREE);'.
>
> Ugh.
>
> I hate POLLFREE, and the more I look at this, the more I think it's broken.
>
> And that
>
> wake_up_poll(wq, EPOLLHUP | POLLFREE);
>
> in particular looks broken - the intent is that it should remove all
> the wait queue entries (because the wait queue head is going away),
> but wake_up_poll() iself actually does
>
> __wake_up(x, TASK_NORMAL, 1, poll_to_key(m))
>
> where that '1' is the number of exclusive entries it will wake up.
>
> So if there are two exclusive waiters, wake_up_poll() will simply stop
> waking things up after the first one.
>
> Which defeats the whole POLLFREE thing too.
>
> Maybe I'm missing something, but POLLFREE really is broken.
>
> I'd argue that all of epoll() is broken, but I guess we're stuck with it.
>
> Now, it's very possible that nobody actually uses exclusive waits for
> those wait queues, and my "nr_exclusive" argument is about something
> that isn't actually a bug in reality. But I think it's a sign of
> confusion, and it's just another issue with POLLFREE.
>
> I really wish we could have some way to not have epoll and aio mess
> with the wait-queue lists and cache the wait queue head pointers that
> they don't own.
>
> In the meantime, I don't think these patches make things worse, and
> they may fix things. But see above about "nr_exclusive" and how I
> think wait queue entries might end up avoiding POLLFREE handling..
>
> Linus
epoll supports exclusive waits, via the EPOLLEXCLUSIVE flag. So this looks like
a real problem.
It could be fixed by converting signalfd and binder to use something like this,
right?
#define wake_up_pollfree(x) \
__wake_up(x, TASK_NORMAL, 0, poll_to_key(EPOLLHUP | POLLFREE))
As for eliminating POLLFREE entirely, that would require that the waitqueue
heads be moved to a location which has a longer lifetime. I'm not sure if
that's possible. In the case of signalfd, maybe the waitqueue head could be
moved to the file private data (signalfd_ctx), and then sighand_struct would
contain a list of signalfd_ctx's which are receiving signals directed to that
sighand_struct, rather than the waitqueue head itself. I'm not sure how well
that would work. This would probably change user-visible behavior; if a
signalfd is inherited by fork(), the child process would be notified about
signals sent to the parent process, rather than itself as is currently the case.
- Eric
next prev parent reply other threads:[~2021-12-06 19:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-04 0:22 [PATCH 0/2] aio poll: fix use-after-free and missing wakeups Eric Biggers
2021-12-04 0:23 ` [PATCH 1/2] aio: keep poll requests on waitqueue until completed Eric Biggers
2021-12-06 18:56 ` Eric Biggers
2021-12-04 0:23 ` [PATCH 2/2] aio: fix use-after-free due to missing POLLFREE handling Eric Biggers
2021-12-06 19:28 ` Linus Torvalds
2021-12-06 19:54 ` Eric Biggers [this message]
2021-12-06 21:48 ` Linus Torvalds
2021-12-07 10:21 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ya5qWLLv3i4szS4N@gmail.com \
--to=ebiggers@kernel.org \
--cc=axboe@kernel.dk \
--cc=bcrl@kvack.org \
--cc=hch@lst.de \
--cc=linux-aio@kvack.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=ramjiyani@google.com \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).