Accepting request 1098813 from home:dirkmueller:Factory

- 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/1098813
OBS-URL: https://build.opensuse.org/package/show/devel:libraries:c_c++/nghttp2?expand=0&rev=113

nghttp2-1.54.0.tar.xz

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:20533c9354fbb6aa689b6aa0ddb77f91da1d242587444502832e1864308152df
-size 1541460

nghttp2-1.55.1.tar.xz

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:19490b7c8c2ded1cf7c3e3a54ef4304e3a7876ae2d950d60a81d0dc6053be419
+size 1541884

nghttp2.changes

@@ -1,3 +1,49 @@
+-------------------------------------------------------------------
+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
+
+-------------------------------------------------------------------
+Sat Jul 15 15:11:42 UTC 2023 - Dirk Müller <dmueller@suse.com>
+
+- update to 1.55.1: 
+
 -------------------------------------------------------------------
 Tue Jun 20 20:48:11 UTC 2023 - Dirk Müller <dmueller@suse.com>
 

nghttp2.spec

@@ -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