Messages in this thread | | | Date | Mon, 1 Mar 1999 18:30:11 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [patch] af_unix fix for a panic a DoS and a memory leak [Re: |
| |
On Tue, 2 Mar 1999, Andrea Arcangeli wrote:
> On Mon, 1 Mar 1999, Alexander Viro wrote: > > >limit. And if I read the unix_release_sock() right we do not remove > >corresponding skb's from the listen queue. Oh, fsck! It may explain the > > Hmm unix_release_sock(sk) should destroy all skb queued to sk sock (see > unix_destroy_sock()). > > >unix_gc() breakage - we may end up doing funny things to dead sockets. > > > >What about > >257c257 > >< if (UNIXCB(skb).attr & MSG_SYN) { > >--- > >> if ((UNIXCB(skb).attr & MSG_SYN) && !skb->sk->dead) { > > If you use `!' you are allowing a dead socket to be shrunk from the > garbage collector. So in the garbage collector we are just not touching > peer-dead-socks awaiting for an accept().
Don't trace their queues.
> 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 and then kill them on reap phase. Or simply kill the peer skb immediately on unix_release_sock().
- 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/
| |