netdev - SCTP's processing of unexpected COOKIE

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Jun 2014 09:52:07 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: SCTP's processing of unexpected COOKIE_ECHO doesn't seem useful.

I'm seeing some unexpected (to me) behaviour of the SCTP stack
when the remote system restarts.

I've a socket that has a single association, and I'm rather
expecting TCP-like behaviour.
So I'd expect some kind of failure condition on my existing
connection, and then a new connection be established on a
different socket - eg though a listening socket.
This would then go through all my code for correctly
initialising a new connection.

What happens is rather different.

The remote sends an INIT with the same port numbers as the
previous connection, AFAICT the code sends an INIT_ACK with
some numbers taken from the existing TCB.

When the COOKIE_ECHO is received sctp_sf_do_5_2_4_dupcook()
is called, condition 'A' is detected and sctp_sf_do_dupcook_a()
called.

RFC 2960 says that this should be treated as a received ABORT
followed by a COOKIE echo - this sounds fine, I want the ABORT
processing to kill the existing connection.
However it then says that 'RESTART' should be indicated to the ULP
rather than 'COMMUNICATION LOST'.

AFAICT this is just silently ignored by the socket layer.
I've a process sleeping in recv() (actually a kernel thread in
sock_recvmsg()) and it is not woken up at all.

This leaves the 'application' code in completely the wrong state for
the SCTP connection.

ISTM that the mapping of SCTP to connection-mode sockets should be
treating this as a disconnect.

This scenario can be reproduced by disconnecting with ABORT and
getting iptables to discard the ABORT.
It can happen with some connection retry algorithms if there is
message loss.

	David

--
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