| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| no-tokio-rustls.patch | =================================================================== | no | ||||
| disable-test-missing-testdata.patch | =================================================================== | no | ||||
| no-webpki-roots.patch | =================================================================== | no | ||||
| limit-pending-accept-reset-streams.patch | commit 5bc8e72e5fcbd8ae2d3d9bc78a1c0ef0040bcc39 fix: limit the amount of pending-accept reset streams Streams that have been received by the peer, but not accepted by the user, can also receive a RST_STREAM. This is a legitimate pattern: one could send a request and then shortly after, realize it is not needed, sending a CANCEL. However, since those streams are now "closed", they don't count towards the max concurrent streams. So, they will sit in the accept queue, using memory. In most cases, the user is calling `accept` in a loop, and they can accept requests that have been reset fast enough that this isn't an issue in practice. But if the peer is able to flood the network faster than the server accept loop can run (simply accepting, not processing requests; that tends to happen in a separate task), the memory could grow. So, this introduces a maximum count for streams in the pending-accept but remotely-reset state. If the maximum is reached, a GOAWAY frame with the error code of ENHANCE_YOUR_CALM is sent, and the connection marks itself as errored. ref CVE-2023-26964 ref GHSA-f8vr-r385-rh5r Closes https://github.com/hyperium/hyper/issues/2877 diff --git a/src/proto/connection.rs b/src/proto/connection.rs index 59883cf33..1fec23102 100644 |
Sean McArthur <sean@seanmonstar.com> | no | 2023-04-12 | ||
| fix-regression.patch | commit 1c6fa285afe436ca2a1f8abd38a6389353f360b6 fix: pending-accept remotely-reset streams pattern was checking is_local diff --git a/src/proto/streams/state.rs b/src/proto/streams/state.rs index b9612addc..76638fc87 100644 |
Sean McArthur <sean@seanmonstar.com> | no | 2023-04-17 |