> On Mon, 1 Mar 1999, Alexander Viro wrote:
>
> >> And if the sock is dead I can't see major problems in playing with it as
> >> far as the code has the big kernel lock held and unix_gc() doesn't sleep.
> >
> > Except that unix_destroy_timer() can kfree() it at any moment. And
> >*that* is not protected by kernel_lock.
> > Proper behaviour would be to take those skb's to a separate list
>
> It looks me quite clear that the _only_ thing that can be freed at any
> moment is the sock and _not_ the skb in the sock queue. And as just said
> the sock is just unhashed when unix_gc is running.
Wonderful. So what will happen if we will include that sock (unhashed, all
such, but referenced from the skb in listen queue) into the stack, add few
more from the same queue and then try to pop them?
> >and then kill them on reap phase. Or simply kill the peer skb immediately
> >on unix_release_sock().
>
> I think we are just doing that. Maybe I am missing something due the late
> time I am writing this...
Yes, you are. unix_release_sock() doesn't take the peer skb out of the listen
queue. Heck, that's what your own exploit is based upon - you are creating
connection and closing it without accept() on the other side and it leaves
peer skb's in the listen queue.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/