linux-kernel - RE: epoll and closed file descriptors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Sep 2009 17:53:05 -0700
From:	"Gilad Benjamini" <gilad@...ornetworks.com>
To:	"'Bryan Donlan'" <bdonlan@...il.com>
Cc:	"'Davide Libenzi'" <davidel@...ilserver.org>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>
Subject: RE: epoll and closed file descriptors

> Subject: Re: epoll and closed file descriptors
> 
> On Wed, Sep 16, 2009 at 8:40 PM, Gilad Benjamini
> <gilad@...ornetworks.com> wrote:
> > Davide wrote:
> >> On Wed, 16 Sep 2009, Gilad Benjamini wrote:
> >>
> >> > I would, but epoll is preventing me from doing so.
> >> > Early in sys_epoll_ctl there are these lines
> >> >
> >> >   file = fget(epfd);
> >> >   if (!file)
> >> >     goto error_return;
> >> >
> >> > Leaving me in a kind of dead lock
> >>
> >> The 'epfd' in there, is the _epoll fd_, which, if fget() fails,
> means
> >> you
> >> close it.
> >> You see likely failing the 'tfile = fget(fd)' (of course, you closed
> >> it),
> >> so if someone else keeps the socket open and you have no chance in
> >> telling
> >> it to drop it (really?), you need to remove the socket from the set
> >> before
> >> closing it.
> >>
> >>
> >>
> >> - Davide
> >
> > My bad. I meant to quote the line that you mentioned.
> > I agree that the right thing to do is to remove the fd from epoll
> before
> > closing it.
> > However, due to the way curl works, I cannot do that. Changing the
> curl code
> > doesn't seem trivial.
> >
> > Regardless, I still don't see how the kernel got into this situation,
> and if
> > this situation is valid, why it doesn't bail out of it.
> 
> epoll references the underlying file object; the fd is used _only_ to
> obtain this file object, and then never used again. Determining when
> the fd goes away then requires iterating over all fds, and since epoll
> was designed to avoid doing exactly that, it isn't an acceptable
> solution.

Regarding bailing out of the situation, I see the logic in your answer.
What about the first part ? Any ideas how the kernel actually got into that
tight spot ?
Looking into the code I can't find a path that can lead into this situation.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/