stable-bot: Bugfixes waiting for a release 2.3 (5), 2.1 (7), 2.0 (11)
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 2.3.9 was issued on 2021-03-30. There are currently 5 patches in the queue cut down this way: - 5 MINOR, first one merged on 2021-03-31 Thus the computed ideal release date for 2.3.10 would be 2021-04-28, which is in three weeks or less. Last release 2.1.12 was issued on 2021-03-18. There are currently 7 patches in the queue cut down this way: - 4 MEDIUM, first one merged on 2021-03-31 - 3 MINOR, first one merged on 2021-03-31 Thus the computed ideal release date for 2.1.13 would be 2021-05-26, which is in seven weeks or less. Last release 2.0.21 was issued on 2021-03-18. There are currently 11 patches in the queue cut down this way: - 1 BUG, first one merged on 2021-03-24 - 6 MEDIUM, first one merged on 2021-03-24 - 4 MINOR, first one merged on 2021-03-31 Thus the computed ideal release date for 2.0.22 would be 2021-05-19, which is in six weeks or less. The current list of patches in the queue is: - 2.0 - BUG : mworker/cli: do not use the unix_bind prefix for the master CLI socket - 2.0, 2.1 - MEDIUM : thread: Fix a deadlock if an isolated thread is marked as harmless - 2.0 - MEDIUM : lua: Always init the lua stack before referencing the context - 2.0 - MEDIUM : debug/lua: Use internal hlua function to dump the lua traceback - 2.0, 2.1 - MEDIUM : mux-h1: make h1_shutw_conn() idempotent - 2.0, 2.1 - MEDIUM : freq_ctr/threads: use the global_now_ms variable - 2.0, 2.1 - MEDIUM : time: make sure to always initialize the global tick - 2.0, 2.1 - MINOR : http_fetch: make hdr_ip() reject trailing characters - 2.0, 2.1, 2.3 - MINOR : tcp: fix silent-drop workaround for IPv6 - 2.0 - MINOR : stats: Apply proper styles in HTML status page. - 2.3 - MINOR : ssl: Fix update of default certificate - 2.3 - MINOR : ssl: Add missing free on SSL_CTX in ckch_inst_free - 2.0, 2.1, 2.3 - MINOR : http_fetch: make hdr_ip() resistant to empty fields - 2.3 - MINOR : ssl: Prevent removal of crt-list line if the instance is a default one -- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
Re: [PATCH] JWT payloads break b64dec convertor
Hi Moemen,
On Tue, Apr 06, 2021 at 01:58:11AM +0200, Moemen MHEDHBI wrote:
> Only part unclear:
> On 02/04/2021 15:04, Tim Düsterhus wrote:
> >> +int base64urldec(const char *in, size_t ilen, char *out, size_t olen) {
> >> +char conv[ilen+2];
> >
> > This looks like a remotely triggerable stack overflow.
>
> You mean in case ilen is too big?
Yes that's it, I didn't notice it during the first review. It's
particularly uncommon to use variable sized arrays and should never
be done. The immediate effect of this is that it will reserve some
room in the stack for a size as large as ilen+2 bytes. The problem
is that on most platforms the stack grows down, so the beginning of
the buffer is located at a point which is very far away from the
current stack. This memory is in fact not allocated, so the system
detects the first usage through a page fault and allocates the
necessary space. But in order to know that the page fault is within
the stack, it has to apply a certain margin. And this margin varies
between OSes and platforms. Some compilers will explicitly initialize
such a large stack from top to bottom to avoid a crash. Other ones
will not do and may very well crash at 64kB. On Linux, I can make the
above crash by using a 8 MB ilen, just because by default the stack
size limit is 8 MB. That's large but not overly excessive for those
who would like to perform some processing on bodies. And I recall
that some other OSes default to way smaller limits (I recall 64kB
on OpenBSD a long time ago though this might have been raised to a
megabyte or so by now).
> in such case should we rather use dynamic allocation ?
No, there are two possible approaches. One of them is to use a trash
buffer using get_trash_chunk(). The trash buffers are "large enough"
for anything that comes from outside. A second, cleaner solution
simply consists in not using a temporary buffer but doing the conversion
on the fly. Indeed, looking closer, what the function does is to first
replace a few chars on the whole chain to then call the base64 conversion
function. So it doubles the work on the string and one side effect of
this double work is that you need a temporary storage.
Other approaches would consist in either reimplementing the functions
with a different alphabet, or modifying the existing ones to take an
extra argument for the conversion table, and make one set of functions
making use of the current table and another set making use of your new
table.
Willy
