Karsten, Michal

I think I found this cursed race.

The problem is that nothing is guarding the asoc->base.sk reference.  This
reference changes during the accept()/peeloff() code paths and the only
guard around it is the socket lock.  But that lock is not taken when
the reference is used for reading as it is done in sctp_rcv().

So, when we do sctp_bh_lock_sock(sk) in sctp_rcv(), we may be using
a stale cached copy of the sk which might have changed during sctp_accept().

What this allows us to do is to have a user sending a packet on a socket
at the same time we may be processing and incoming packet on the same socket.
We just end up taking different locks which totally hoses us.

-vlad