| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 01-fix-sphinxdoc-conf.patch | Don't try to detect the version, don't use Pylons theme. | Andrew Shadura <andrewsh@debian.org> | no | |||
| CVE-2022-24761-1.patch | Add new regular expressions for Chunked Encoding This also moves some regular expressions for QUOTED_PAIR/QUOTED_STRING into this module from utilities so that they may be reused. Part of CVE-2022-24761 |
Bert JW Regeer <bertjw@regeer.org> | no | 2022-03-12 | ||
| CVE-2022-24761-2.patch | Be more strict in parsing Content-Length Validate that we are only parsing digits and nothing else. RFC7230 is explicit in that the Content-Length can only exist of 1*DIGIT and may not include any additional sign information. The Python int() function parses `+10` as `10` which means we were more lenient than the standard intended. Part of CVE-2022-24761 |
Bert JW Regeer <bertjw@regeer.org> | no | 2022-03-12 | ||
| CVE-2022-24761-3.patch | Update tests to remove invalid chunked encoding chunk-size RFC7230 states the following: chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF chunk-size = 1*HEXDIG Where chunk-ext is: chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) Only if there is a chunk-ext should there be a `;` after the 1*HEXDIG. And a chunk-ext that is empty is invalid. Part of CVE-2022-24761 |
Bert JW Regeer <bertjw@regeer.org> | no | 2022-03-12 | ||
| CVE-2022-24761-4.patch | Error when receiving back Chunk Extension Waitress discards chunked extensions and does no further processing on them, however it failed to validate that the chunked encoding extension did not contain invalid data. We now validate that if there are any chunked extensions that they are well-formed, if they are not and contain invalid characters, then Waitress will now correctly return a Bad Request and stop any further processing of the request. Part of CVE-2022-24761 |
Bert JW Regeer <bertjw@regeer.org> | no | 2022-03-12 | ||
| CVE-2022-24761-5.patch | Validate chunk size in Chunked Encoding are HEXDIG RFC7230 states that a chunk-size should be 1*HEXDIG, this is now validated before passing the resulting string to int() which would also parse other formats for hex, such as: `0x01` as `1` and `+0x01` as `1`. This would lead to a potential for a frontend proxy server and waitress to disagree on where a chunk started and ended, thereby potentially leading to request smuggling. With the increased validation if the size is not just hex digits, Waitress now returns a Bad Request and stops processing the request. Part of CVE-2022-24761 |
Bert JW Regeer <bertjw@regeer.org> | no | 2022-03-12 | ||
| CVE-2022-24761-6.patch | Remove extraneous calls to .strip() in Chunked Encoding To be valid chunked encoding we should not be removing any whitespace as the standard does not allow for optional whitespace. If whitespace is encountered in the wrong place, it should lead to a 400 Bad Request instead. Part of CVE-2022-24761 |
Bert JW Regeer <bertjw@regeer.org> | no | 2022-03-12 | ||
| 0001-Remove-test-for-getpeername.patch | Remove test for getpeername() | Delta Regeer <bertjw@regeer.org> | no | 2024-03-03 | ||
| 0002-When-closing-the-socket-set-it-to-None.patch | When closing the socket, set it to None This avoids calling close() twice on the same socket if self.close() or self.handle_close() is called multiple times |
Delta Regeer <bertjw@regeer.org> | no | 2024-03-03 | ||
| 0003-Don-t-exit-handle_write-early-even-if-socket-is-not-.patch | Don't exit handle_write early -- even if socket is not connected Calling handle_close() multiple times does not hurt anything, and is safe. |
Delta Regeer <bertjw@regeer.org> | no | 2024-03-03 | ||
| 0004-Assume-socket-is-not-connected-when-passed-to-wasync.patch | Assume socket is not connected when passed to wasyncore.dispatcher No longer call getpeername() on the remote socket either, as it is not necessary for any of the places where waitress requires that self.addr in a subclass of the dispatcher needs it. This removes a race condition when setting up a HTTPChannel where we accepted the socket, and know the remote address, yet call getpeername() again which would have the unintended side effect of potentially setting self.connected to False because the remote has already shut down part of the socket. This issue was uncovered in #418, where the server would go into a hard loop because self.connected was used in various parts of the code base. |
Delta Regeer <bertjw@regeer.org> | no | 2024-03-03 | ||
| 0005-HTTPChannel-is-always-created-from-accept-explicitly.patch | HTTPChannel is always created from accept, explicitly set self.connected to True | Delta Regeer <bertjw@regeer.org> | no | 2024-03-03 |