Merge branch '3112-ensure-correct-ordering-in-isc__nm_process_sock_buffer' into 'main'

[CVE-2022-0396] Resolve #3112 TCP sockets stuck in CLOSE_WAIT

Closes #3112

See merge request !5987

CHANGES

@@ -39,7 +39,12 @@
 5819.	[placeholder]
-5818.	[placeholder]
+5818.	[security]	A synchronous call to closehandle_cb() caused
+			isc__nm_process_sock_buffer() to be called recursively,
+			which in turn left TCP connections hanging in the
+			CLOSE_WAIT state blocking indefinitely when
+			out-of-order processing was disabled. (CVE-2022-0396)
+			[GL #3112]
 5817.	[security]	The rules for acceptance of records into the cache
 			have been tightened to prevent the possibility of

doc/notes/notes-current.rst

@@ -24,6 +24,11 @@ Security Fixes
   Changgen Zou from Qi An Xin Group Corp. for bringing this
   vulnerability to our attention. :gl:`#2950`
 
+- TCP connections with ``keep-response-order`` enabled could leave the
+  TCP sockets in the ``CLOSE_WAIT`` state when the client did not
+  properly shut down the connection. (CVE-2022-0396) :gl:`#3112`
+
+
 Known Issues
 ~~~~~~~~~~~~
 

lib/isc/netmgr/netmgr.c

@@ -1731,8 +1731,12 @@ isc__nmhandle_detach(isc_nmhandle_t **handlep FLARG) {
 	handle = *handlep;
 	*handlep = NULL;
 
+	/*
+	 * If the closehandle_cb is set, it needs to run asynchronously to
+	 * ensure correct ordering of the isc__nm_process_sock_buffer().
+	 */
 	sock = handle->sock;
-	if (sock->tid == isc_nm_tid()) {
+	if (sock->tid == isc_nm_tid() && sock->closehandle_cb == NULL) {
 		nmhandle_detach_cb(&handle FLARG_PASS);
 	} else {
 		isc__netievent_detach_t *event =