From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Davide Libenzi <davidel@xmailserver.org>,
Eric Dumazet <eric.dumazet@gmail.com>, Greg KH <greg@kroah.com>,
Jason Baron <jbaron@redhat.com>,
Roland McGrath <roland@hack.frob.com>,
Eugene Teo <eugeneteo@kernel.sg>,
Maxime Bizon <mbizon@freebox.fr>,
Denys Vlasenko <dvlasenk@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/2] signalfd/epoll fixes
Date: Sat, 25 Feb 2012 17:08:45 +0100 [thread overview]
Message-ID: <20120225160845.GA13324@redhat.com> (raw)
In-Reply-To: <CA+55aFyPCHiESkfGMLOA7vNYz46FOnTrvQFJhwCFz9wAehP=7w@mail.gmail.com>
On 02/24, Linus Torvalds wrote:
>
> On Fri, Feb 24, 2012 at 12:23 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > I'm *really* conflicted, because I have this really strong feeling
> > that it's just papering over a symptom, and we damn well shouldn't be
> > doing that.
Heh. This is even documented in the changelog.
> I really think that what we really should do is allow
> > "poll()" to have a "poll_remove" callback (so each "add_poll_wait()"
> > will have a callback when it gets remove).
Yes. I also thought about this. In fact I think this probably makes
sense even ignoring epoll problems. Although I was thinking about
file_operations::poll_v2(file, poll_table, poll_table_entry, mode)
which could could replace the old ->poll() eventually. But perhaps
the explicit poll_rm() is better.
However, speaking about epoll/sigfd, imho this hides the problem too.
> +static void signalfd_poll_rm(struct file *file, wait_queue_head_t *p)
> +{
> + struct sighand_struct *sighand;
> +
> + sighand = container_of(p, struct sighand_struct, signalfd_wqh);
> + __cleanup_sighand(sighand);
> +}
> +
> static unsigned int signalfd_poll(struct file *file, poll_table *wait)
> {
> struct signalfd_ctx *ctx = file->private_data;
> unsigned int events = 0;
>
> - poll_wait(file, ¤t->sighand->signalfd_wqh, wait);
> + if (poll_wait(file, ¤t->sighand->signalfd_wqh, wait))
> + atomic_inc(¤t->sighand->count);
Yes, this fixes use-after-free. But suppose the the application does:
sigfd = signalfd(...);
epoll_ctl(epollfd, EPOLL_CTL_ADD, sigfd);
execve();
de_thread() unshares ->sighand because of atomic_inc() above and
epollfd no longer works after exec, and the application can't know
this. (yes, currently we have the same problem with CLONE_SIGHAND'ed
apps, but still).
We can turn ->signalfd_wqh into the pointer to the refcountable
memory, or add another counter, but this is not nice.
And in any case. If the task exits, to me it looks simply pointless
to keep its ->sighand until __fput(). This only makes poll_rm() or
whatever safe, it can't report a signal. OK, OK, I am not arguing,
POLLFREE is equally ugly or even worse.
I _think_ that the right fix should move wait_queue_head_t from
sighand_struct to signalfd_ctx (file->private_data) somehow...
Oleg.
next prev parent reply other threads:[~2012-02-25 16:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120222173326.GA7139@redhat.com>
2012-02-22 17:33 ` [PATCH 1/4] signalfd: introduce signalfd_cleanup() Oleg Nesterov
2012-02-22 17:34 ` [PATCH 2/4] epoll: introduce POLLFREE for ep_poll_callback() Oleg Nesterov
2012-02-22 17:34 ` [PATCH 3/4] signalfd: signalfd_cleanup() can race with remove_wait_queue() Oleg Nesterov
2012-02-22 17:35 ` [PATCH 4/4] epoll: ep_unregister_pollwait() can use the freed pwq->whead Oleg Nesterov
2012-02-23 15:44 ` Oleg Nesterov
2012-02-23 22:17 ` Linus Torvalds
2012-02-24 19:06 ` [PATCH v2 0/2] signalfd/epoll fixes Oleg Nesterov
2012-02-24 19:07 ` [PATCH v2 1/2] epoll: introduce POLLFREE to flush ->signalfd_wqh before kfree() Oleg Nesterov
2012-02-29 19:57 ` Andy Lutomirski
2012-02-29 20:06 ` Oleg Nesterov
2012-02-29 20:16 ` Andrew Lutomirski
2012-03-01 19:26 ` Oleg Nesterov
2012-02-24 19:07 ` [PATCH v2 2/2] epoll: ep_unregister_pollwait() can use the freed pwq->whead Oleg Nesterov
2012-02-24 20:23 ` [PATCH v2 0/2] signalfd/epoll fixes Linus Torvalds
2012-02-24 23:14 ` Linus Torvalds
2012-02-25 16:08 ` Oleg Nesterov [this message]
2012-02-25 19:00 ` Linus Torvalds
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=20120225160845.GA13324@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=davidel@xmailserver.org \
--cc=dvlasenk@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=eugeneteo@kernel.sg \
--cc=greg@kroah.com \
--cc=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbizon@freebox.fr \
--cc=roland@hack.frob.com \
--cc=torvalds@linux-foundation.org \
/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).