netdev - SCTP doesn't seem to let you 'cancel' a blocking accept()

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: Mon, 3 Jun 2024 15:39:22 +0000
From: David Laight <David.Laight@...LAB.COM>
To: linux-sctp <linux-sctp@...r.kernel.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: SCTP doesn't seem to let you 'cancel' a blocking accept()

In a multithreaded program it is reasonable to have a thread blocked in accept().
With TCP a subsequent shutdown(listen_fd, SHUT_RDWR) causes the accept to fail.
But nothing happens for SCTP.

I think the 'magic' happens when tcp_disconnect() calls inet_csk_listen_stop(sk)
but sctp_disconnect() is an empty function and nothing happens.

I can't see any calls to inet_csk_listen_stop() in the sctp code - so I suspect
it isn't possible at all.

This all relates to a very old (pre git) comment in inet_shutdown() that
shutdown needs to act on listening and connecting sockets until the VFS
layer is 'fixed' (presumably to let close() through - not going to happen.)

I also suspect that a blocking connect() can't be cancelled either?

Clearly the application can avoid the issue by using poll() and an
extra eventfd() for the wakeup - but it is all a faff for code that
otherwise straight forward.

		David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)