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]
Message-ID: <4faeb583e1d44d82b4e16374b0ad583c@AcuMS.aculab.com>
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)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ