lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 6 Jul 2011 11:49:00 -0400 From: Thomas Graf <tgraf@...radead.org> To: Vladislav Yasevich <vladislav.yasevich@...com> Cc: netdev@...r.kernel.org, davem@...emloft.net, Wei Yongjun <yjwei@...fujitsu.com>, Sridhar Samudrala <sri@...ibm.com>, linux-sctp@...r.kernel.org Subject: Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown On Wed, Jul 06, 2011 at 10:31:56AM -0400, Vladislav Yasevich wrote: > >>> + * > >>> + * Allow the association to timeout if SHUTDOWN is > >>> + * pending in case the receiver stays in zero window > >>> + * mode forever. > >>> */ > >>> if (!q->asoc->peer.rwnd && > >>> !list_empty(&tlist) && > >>> - (sack_ctsn+2 == q->asoc->next_tsn)) { > >>> + (sack_ctsn+2 == q->asoc->next_tsn) && > >>> + !(q->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)) { > >> > >> Would a test for (q->asoc->state != SCTP_STATE_SHUTDOWN_PENDING) be clearer? We only > >> care about the PENDING state here. > > > > I think SHUTDOWN_RECEIVED should also be included. We continue to transmit and > > process SACKs after receiving a SHUTDOWN. > > I am not sure about SHUTDOWN_RECEIVED. If we received shutdown, then we are not in > a 0 window situation. Additionally, the sender of the SHUTDOWN started the GUARD timer > and will abort after it expires. So there is no special handling on our part. Why can't we be in a 0 window situation? A well behaving sctp peer may not, but we're on the Internet, everyone behaves at their worst :-) Seriously, this would make for a simple dos. Establish a stream, don't ack any data to make sure there is something on the retransmission queue of the peer. Immediately shutdown the stream and ack any retransmission attempt with a_rwnd=0 to keep the association around forever. Starting the T5 SHUTDOWN GUARD timer is specified as MAY and not MUST so even in a well behaving world we could not really rely on it. Alternatively the peer could just be buggy as well. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists