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]

Message-ID: <3e8340490909161745h5c58c165j1726c3433df3baeb@mail.gmail.com>
Date:	Wed, 16 Sep 2009 20:45:18 -0400
From:	Bryan Donlan <bdonlan@...il.com>
To:	Gilad Benjamini <gilad@...ornetworks.com>
Cc:	Davide Libenzi <davidel@...ilserver.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
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.

As I mentioned in the other email, by dup()ing the file descriptor,
you can get control over when the copy is closed without changing
curl. Then just make sure to remove it from the epoll set before
closing your copy.
--
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/