netdev - RE: [PATCH net-next v3 3/3] net: sctp: Add support for MSG

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Jul 2014 15:22:21 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Vlad Yasevich' <vyasevich@...il.com>,
	"Linux Networking Development Mailing List" <netdev@...r.kernel.org>,
	"'linux-sctp@...r.kernel.org'" <linux-sctp@...r.kernel.org>
CC:	David Miller <davem@...emloft.net>
Subject: RE: [PATCH net-next v3 3/3] net: sctp: Add support for MSG_MORE on
 SCTP

...
> > All this is really defining the behaviour for 'broken' apps.
> > It wouldn't be completely unreasonable if a single message sent with 'MSG_MORE'
> > never actually got sent.
> 
> Actually, this code opens up a way to eat kernel memory.  Consider an application
> that does:
>    while (1) {
>        socket(IPPROTO_SCTP);
>        connect()
>        sendmsg(MSG_MORE); <- write 1 byte
>        close();
>    }
> 
> Because we send with MSG_MORE, the 1 byte gets queued to the association.  The close()
> causes us to enter SHUTDOWN_PENDING state and we never flush the buffer and close
> the association.
> 
> This is a malicious example.  Similarly, a broken application could just forget to
> clear MSG_MORE and when we end up in a condition where the amount of queued data is
> smaller then MTU and all inflight data has been acked, we'd once again be stuck.

>From a system point of view that one doesn't really matter.

> Just because application isn't doing the right thing, we can't assume it's broken.  It
> could be malicious.  We need to make this behavior robust.

Hmmm....
The amount of data per-socket is limited by the mtu and socket buffer size,
so a malicious app would have to create a lot of sockets to use a significant
amount of kernel memory.

If close() blocks forever, isn't there a worse problem with a remote app
that causes the window to be zero - and so data can't be sent and the
close will block forever anyway?
I've never liked protocols that wait forever for send data to drain on disconnect.
Seems like an 'accident' waiting to happen.

I'm not sure what would be needed to be done to cause queued send data to be
sent when SCTP_F_TX_MSG_MORE is cleared by close() or set/clear SCTP_NODELAY.
It is probably a simple call to the correct function.

	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