!87 fix CVE-2022-0396

From: @jiangheng12 
Reviewed-by: @zengwefeng 
Signed-off-by: @zengwefeng
This commit is contained in:
openeuler-ci-bot 2022-03-30 06:01:41 +00:00 committed by Gitee
commit e94219e77c
No known key found for this signature in database
GPG Key ID: 173E9B9CA92EEF8F
2 changed files with 90 additions and 1 deletions

79
CVE-2022-0396.patch Normal file
View File

@ -0,0 +1,79 @@
From bfa4b9c1418ca1ae504f3474e8ffe6fddb6d3e98 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ond=C5=99ej=20Sur=C3=BD?= <ondrej@isc.org>
Date: Tue, 8 Feb 2022 12:42:34 +0100
Subject: [PATCH] Run .closehandle_cb asynchrounosly in nmhandle_detach_cb()
When sock->closehandle_cb is set, we need to run nmhandle_detach_cb()
asynchronously to ensure correct order of multiple packets processing in
the isc__nm_process_sock_buffer(). When not run asynchronously, it
would cause:
a) out-of-order processing of the return codes from processbuffer();
b) stack growth because the next TCP DNS message read callback will
be called from within the current TCP DNS message read callback.
The sock->closehandle_cb is set to isc__nm_resume_processing() for TCP
sockets which calls isc__nm_process_sock_buffer(). If the read callback
(called from isc__nm_process_sock_buffer()->processbuffer()) doesn't
attach to the nmhandle (f.e. because it wants to drop the processing or
we send the response directly via uv_try_write()), the
isc__nm_resume_processing() (via .closehandle_cb) would call
isc__nm_process_sock_buffer() recursively.
The below shortened code path shows how the stack can grow:
1: ns__client_request(handle, ...);
2: isc_nm_tcpdns_sequential(handle);
3: ns_query_start(client, handle);
4: query_lookup(qctx);
5: query_send(qctcx->client);
6: isc__nmhandle_detach(&client->reqhandle);
7: nmhandle_detach_cb(&handle);
8: sock->closehandle_cb(sock); // isc__nm_resume_processing
9: isc__nm_process_sock_buffer(sock);
10: processbuffer(sock); // isc__nm_tcpdns_processbuffer
11: isc_nmhandle_attach(req->handle, &handle);
12: isc__nm_readcb(sock, req, ISC_R_SUCCESS);
13: isc__nm_async_readcb(NULL, ...);
14: uvreq->cb.recv(...); // ns__client_request
Instead, if 'sock->closehandle_cb' is set, we need to run detach the
handle asynchroniously in 'isc__nmhandle_detach', so that on line 8 in
the code flow above does not start this recursion. This ensures the
correct order when processing multiple packets in the function
'isc__nm_process_sock_buffer()' and prevents the stack growth.
When not run asynchronously, the out-of-order processing leaves the
first TCP socket open until all requests on the stream have been
processed.
If the pipelining is disabled on the TCP via `keep-response-order`
configuration option, named would keep the first socket in lingering
CLOSE_WAIT state when the client sends an incomplete packet and then
closes the connection from the client side.
---
lib/isc/netmgr/netmgr.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/isc/netmgr/netmgr.c b/lib/isc/netmgr/netmgr.c
index cabe9d5..c405a9b 100644
--- a/lib/isc/netmgr/netmgr.c
+++ b/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 =
--
1.8.3.1

View File

@ -30,7 +30,7 @@ Summary: The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) serv
Name: bind
License: MPLv2.0
Version: 9.16.23
Release: 1
Release: 2
Epoch: 32
Url: https://www.isc.org/downloads/bind/
#
@ -79,6 +79,8 @@ Patch157:bind-9.11-fips-tests.patch
# https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/2689
Patch164:bind-9.11-rh1666814.patch
Patch6000: CVE-2022-0396.patch
%{?systemd_ordering}
Requires: coreutils
Requires: shadow-utils
@ -369,6 +371,8 @@ in HTML and PDF format.
%patch157 -p1 -b .fips-tests
%patch164 -p1 -b .rh1666814
%patch6000 -p1
%if %{with PKCS11}
%patch135 -p1 -b .config-pkcs11
cp -r bin/named{,-pkcs11}
@ -1090,6 +1094,12 @@ fi;
%endif
%changelog
* Wed Mar 30 2022 jiangheng<jiangheng12@huawei.com> - 9.16.23-2
- Type:CVE
- CVE:CVE-2022-0396
- SUG:NA
- DESC:fix CVE-2022-0396
* Thu Dec 02 2021 jiangheng<jiangheng12@huawei.com> - 9.16.23-1
- DESC:update to 9.16.23