lkml.org 
[lkml]   [1999]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:50    [W:5.724 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site