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 [1] issued
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 defines 2 fatal error codes:
- NGHTTP2_ERR_NOMEM
- NGHTTP2_ERR_CALLBACK_FAILURE
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.
[1] https://github.com/envoyproxy/envoy/security/advisories/GHSA-jfxv-29pc-x22r
[2] https://github.com/nghttp2/nghttp2/pull/1929
Add nghttp2_check_header_value_rfc9113 which verifies the additional
rule imposed by RFC 9113, section 8.2.1, that is a field value must
not start or end with 0x20(SPC) or 0x09(HTAB).
libnghttp2 uses this new function internally.
Add nghttp2_option_set_server_fallback_rfc7540_priorities. If it is
set to nonzero, and server submits SETTINGS_NO_RFC7540_PRIORITIES = 1,
but it does not receive SETTINGS_NO_RFC7540_PRIORITIES from client,
server falls back to RFC 7540 priorities. Only minimal set of
features are enabled in this fallback case.
This commit adds PRIORITY_UPDATE frame support. Applying incoming
PRIORITY_UPDATE frame to server push stream is not implemented.
Client can send PRIORITY_UPDATE frame by calling
nghttp2_submit_priority_update.
Server opts to receive PRIORITY_UPDATE frame by the call
nghttp2_option_set_builtin_recv_extension_type(option,
NGHTTP2_PRIORITY_UPDATE), and passing the option to
nghttp2_session_server_new2 or nghttp2_session_server_new3.
This commit implements RFC 9218 extensible prioritization scheme. It
is enabled when a local endpoint submits
SETTINGS_NO_RFC7540_PRIORITIES = 1. This commit only handles priority
signal in HTTP request header field. Priority header field in
PUSH_PROMISE is not supported.
HTTP messaging must be enabled to take advantage of this
prioritization scheme because HTTP fields are not parsed if HTTP
messaging is disabled.
Fix the bug that causes a stream to stall when a receiver, which
enables nghttp2_option_set_no_auto_window_update() option on, sends
SETTINGS_INITIAL_WINDOW_SIZE with the value that is less than or equal
to the amount of data received. Previously, in this particular case,
when SETTINGS is acknowledged by the sender, the receiver does not try
to send WINDOW_UPDATE frame. The sender is unable to send more data
because its stream-level window size is smaller than or equal to the
amount of data it has sent.
When applying new header table size acknowledged with SETTINGS ACK by
an encoder, change the header table size on a decoder only when it
strictly lowers the current maximum table size set by Dynamic Table
Size Update from the encoder or the default size 4096 if no Dynamic
Table Size Update is received.
Previously, the header table size on a decoder is always changed. If
a maximum size in SETTINGS are increased (e.g., 4096 -> 8192), and
then decreased to the previous value, the decoder incorrectly requires
Dynamic Table Size Update from an encoder.
Previously, if automatic window update is enabled (which is default),
after window size is set to 0 by
nghttp2_session_set_local_window_size, once the receiving window is
exhausted, even after window size is increased by
nghttp2_session_set_local_window_size, no more data cannot be
received. This is because nghttp2_session_set_local_window_size does
not submit WINDOW_UPDATE. It is only triggered when new data arrives
but since window is filled up, no more data cannot be received, thus
dead lock happens.
This commit fixes this issue. nghttp2_session_set_local_window_size
submits WINDOW_UPDATE if necessary.
https://github.com/curl/curl/issues/4939
Add the currently-unused `test_nghttp2_session_create_idle_stream()`
function to the test suite definition.
Modify the test in two places to make it pass:
* Use stream ID=10 as the priority stream ID to test automatic creation
of streams for priority specs. The code below checks against stream
ID=10 so I assume this was a typo in the test.
* Set the `last_sent_stream_id` instead of the `next_stream_id` to test
that idle streams cannot be created with smaller numbers than the
most-recently-seen stream ID. Looking at the validation path in
`session_detect_idle_stream()`, I think this was another test typo.
This commit fixes the bug that stream is closed with wrong error code
(0). This happens when STREAM or DATA frame with END_STREAM flag set
is received and it violates HTTP messaging rule (i.e., content-length
does not match) and the other side of stream has been closed. In this
case, nghttp2_on_stream_close_callback should be called with nonzero
error code, but previously it is called with 0 (NO_ERROR).
The maximum number of outgoing concurrent streams is initially
limited to 100 to avoid issues when the local endpoint submits
lots of requests before receiving initial SETTINGS frame from
the remote endpoint, since sending them at once to the remote
endpoint could lead to rejection of some of the requests.
This initial limit is overwritten with the value advertised in
SETTINGS_MAX_CONCURRENT_STREAMS setting by the remote endpoint,
but previously, it wasn't lifted if the remote endpoint didn't
advertise that setting (implying no limits), in which case the
limit of 100 was retained, even though it was never advertised
by the remote endpoint.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
