Re: RFC: Too many race conditions.

[David Daney <ddaney at avtrex dot com>]

Andrew Haley wrote:
> David Daney writes:
>  > I have been thinking about:
>  > 
>  > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29604
>  > 
>  > My inclination is to do nothing.  My analysis (int the bug report), 
>  > makes me think that to fix the race, all I/O operations would have to  
>  > enter  a  synchronized block twice.  This would create a tremendous 
>  > overhead.
>  > 
>  > Opinions?
>
> Hmm.  This depends, does it not, on the fact that a blocking call does
> not return when a file descriptor is closed?
No.
>   This sounds to me like a
> bug in the kernel, although perhaps it's a bug that has to be
> maintained for backwards compatibility.  Blocking on a closed soucket
> doesn't sound to me like a fruitful activity.
>   
It is not socket or java specific. I think of it as a defect in Posix 
(reuse of the lowest numbered descriptor possible).

It occurs when one thread is closing a descriptor and another is using it.

In the thread using a descriptor, there is a window between when it can 
test if the descriptor is closed and using the descriptor.  Part of the 
window is in the syscall code in libc and also in the kernel before it 
tests for a valid descriptor.

If during this window, a different thread closes the descriptor and then 
re-uses it (possibly in two threads), the thread using the descriptor 
instead of an error will operate on the wrong descriptor.
> Anyway, I'm with you on the "do nothing" front.  Where does the bug
> really lie, in the library or in the application code?  Decent design
> doesn't usually involve opening a socket in one thread and then
> passing that socket to another thread to close.  Is this an
> exploitable security hole?  I suppose it is.
I think the main place someone would close on a separate thread is with 
an nio socket.  But that does not mean that it is not a problem in other 
places as well.

Any condition where you can read or write arbitrary descriptors with no 
security checks is a potential security hole.

David Daney