Accepting request 1099190 from devel:libraries:c_c++
- update to 1.55.1: * Fix memory leak This commit fixes memory leak that happens when PUSH_PROMISE or HEADERS frame cannot be sent, and nghttp2_on_stream_close_callback fails with a fatal error. For example, if GOAWAY frame has been received, a HEADERS frame that opens new stream cannot be sent. This issue has already been made public via CVE-2023-35945 by envoyproxy/envoy project. During embargo period, the patch to fix this bug was accidentally submitted to nghttp2/nghttp2 repository [2]. And they decided to disclose CVE early. I was notified just 1.5 hours before disclosure. I had no time to respond. PoC described in [1] is quite simple, but I think it is not enough to trigger this bug. While it is true that receiving GOAWAY prevents a client from opening new stream, and nghttp2 enters error handling branch, in order to cause the memory leak, nghttp2_session_close_stream function must return a fatal error. NGHTTP2_ERR_NOMEM, as its name suggests, indicates out of memory. It is unlikely that a process gets short of memory with this simple PoC scenario unless application does something memory heavy processing. * NGHTTP2_ERR_CALLBACK_FAILURE is returned from application defined callback function (nghttp2_on_stream_close_callback, in this case), which indicates something fatal happened inside a callback, and a connection must be closed immediately without any further action. As nghttp2_on_stream_close_error_callback documentation says, any error code other than 0 or NGHTTP2_ERR_CALLBACK_FAILURE is treated as fatal OBS-URL: https://build.opensuse.org/request/show/1099190 OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/nghttp2?expand=0&rev=74
This commit is contained in:
commit
fd3acbe357
@ -1,3 +0,0 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:20533c9354fbb6aa689b6aa0ddb77f91da1d242587444502832e1864308152df
|
||||
size 1541460
|
3
nghttp2-1.55.1.tar.xz
Normal file
3
nghttp2-1.55.1.tar.xz
Normal file
@ -0,0 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:19490b7c8c2ded1cf7c3e3a54ef4304e3a7876ae2d950d60a81d0dc6053be419
|
||||
size 1541884
|
@ -1,3 +1,44 @@
|
||||
-------------------------------------------------------------------
|
||||
Sat Jul 15 15:11:52 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||||
|
||||
- update to 1.55.1:
|
||||
* Fix memory leak
|
||||
This commit fixes memory leak that happens when
|
||||
PUSH_PROMISE or HEADERS frame cannot be sent, and
|
||||
nghttp2_on_stream_close_callback fails with a fatal error.
|
||||
For example, if GOAWAY frame has been received, a
|
||||
HEADERS frame that opens new stream cannot be sent.
|
||||
This issue has already been made public via CVE-2023-35945
|
||||
by envoyproxy/envoy project. During embargo period, the
|
||||
patch to fix this bug was accidentally submitted to
|
||||
nghttp2/nghttp2 repository [2]. And they decided to
|
||||
disclose CVE early. I was notified just 1.5 hours
|
||||
before disclosure. I had no time to respond.
|
||||
PoC described in [1] is quite simple, but I think it is
|
||||
not enough to trigger this bug. While it is true that
|
||||
receiving GOAWAY prevents a client from opening new stream,
|
||||
and nghttp2 enters error handling branch, in order to cause
|
||||
the memory leak, nghttp2_session_close_stream function
|
||||
must return a fatal error.
|
||||
NGHTTP2_ERR_NOMEM, as its name suggests, indicates out of
|
||||
memory. It is unlikely that a process gets short of
|
||||
memory with this simple PoC scenario unless application
|
||||
does something memory heavy processing.
|
||||
* NGHTTP2_ERR_CALLBACK_FAILURE is returned from application
|
||||
defined callback function (nghttp2_on_stream_close_callback, in
|
||||
this case), which indicates something fatal happened inside a
|
||||
callback, and a connection must be closed immediately without
|
||||
any further action. As nghttp2_on_stream_close_error_callback
|
||||
documentation says, any error code other than 0 or
|
||||
NGHTTP2_ERR_CALLBACK_FAILURE is treated as fatal
|
||||
error code. More specifically, it is treated as if
|
||||
NGHTTP2_ERR_CALLBACK_FAILURE is returned. I guess that
|
||||
envoy returns
|
||||
NGHTTP2_ERR_CALLBACK_FAILURE or other error code which is
|
||||
translated into NGHTTP2_ERR_CALLBACK_FAILURE.
|
||||
https://github.com/envoyproxy/envoy/security/advisories/GHSA-
|
||||
jfxv-29pc-x22r
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Tue Jun 20 20:48:11 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||||
|
||||
|
@ -22,7 +22,7 @@
|
||||
%global sover_asio 1
|
||||
%global flavor @BUILD_FLAVOR@%{nil}
|
||||
Name: nghttp2
|
||||
Version: 1.54.0
|
||||
Version: 1.55.1
|
||||
Release: 0
|
||||
Summary: Implementation of Hypertext Transfer Protocol version 2 in C
|
||||
License: MIT
|
||||
|
Loading…
Reference in New Issue
Block a user