Segmentation fault. #24
Labels
Comments
|
wow thank you so much, no trouble at all:) |
|
I knew it.. |
|
Hi, should be fixed in master |
jiangwenyuan
added a commit
that referenced
this issue
Aug 15, 2018
(cherry picked from commit 1c1e3d9)
jiangwenyuan
pushed a commit
that referenced
this issue
Mar 10, 2019
In OpenSSL 1.1.1 TLS 1.3 KeyUpdate messages will trigger the callback that is used to verify renegotiation is disabled. This means that these KeyUpdate messages fail. In OpenSSL 1.1.1 a better mechanism is available with the SSL_OP_NO_RENEGOTIATION flag that disables any TLS 1.2 and earlier negotiation. So if this SSL_OP_NO_RENEGOTIATION flag is available, instead of having a manual check, trust OpenSSL and disable the check. This means that TLS 1.3 KeyUpdate messages will work properly. Reported-By: Adam Langley <[email protected]> (cherry picked from commit 526894f) [wt: gh issue #24; Needs to be backported till 1.8] Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 062c5a1) Signed-off-by: William Lallemand <[email protected]>
jiangwenyuan
pushed a commit
that referenced
this issue
Mar 10, 2019
In OpenSSL 1.1.1 TLS 1.3 KeyUpdate messages will trigger the callback that is used to verify renegotiation is disabled. This means that these KeyUpdate messages fail. In OpenSSL 1.1.1 a better mechanism is available with the SSL_OP_NO_RENEGOTIATION flag that disables any TLS 1.2 and earlier negotiation. So if this SSL_OP_NO_RENEGOTIATION flag is available, instead of having a manual check, trust OpenSSL and disable the check. This means that TLS 1.3 KeyUpdate messages will work properly. Reported-By: Adam Langley <[email protected]> (cherry picked from commit 526894f) [wt: gh issue #24; Needs to be backported till 1.8] Signed-off-by: Willy Tarreau <[email protected]>
jiangwenyuan
added a commit
that referenced
this issue
Feb 13, 2020
(cherry picked from commit 1c1e3d9)
jiangwenyuan
added a commit
that referenced
this issue
Feb 13, 2020
jiangwenyuan
pushed a commit
that referenced
this issue
Feb 13, 2020
Squashed commit of the following: commit ebf033b47d58aa04ae9913038c9369dab8740411 Author: Willy Tarreau <[email protected]> Date: Mon Feb 11 14:16:19 2019 +0100 [RELEASE] Released version 1.8.19 Released version 1.8.19 with the following main changes : - DOC: ssl: Clarify when pre TLSv1.3 cipher can be used - DOC: ssl: Stop documenting ciphers example to use - BUG/MINOR: spoe: do not assume agent->rt is valid on exit - BUG/MINOR: lua: initialize the correct idle conn lists for the SSL sockets - BUG/MEDIUM: spoe: initialization depending on nbthread must be done last - BUG/MEDIUM: server: initialize the idle conns list after parsing the config - BUG/MAJOR: spoe: Don't try to get agent config during SPOP healthcheck - BUG/MAJOR: stream: avoid double free on unique_id - BUG/MINOR: config: Reinforce validity check when a process number is parsed commit 072b42ca7301399fdefa78988c1da227576ab2f8 Author: Christopher Faulet <[email protected]> Date: Thu Feb 7 16:29:41 2019 +0100 BUG/MINOR: config: Reinforce validity check when a process number is parsed Now, in the function parse_process_number(), when a process number or a set of processes is parsed, an error is triggered if an invalid character is found. It means following syntaxes are not forbidden and will emit an alert during the HAProxy startup: 1a 1/2 1-2-3 This bug was reported on Github. See issue #36. This patch may be backported to 1.9 and 1.8. (cherry picked from commit 18cca781f5384f060704ad80018d80bdd4e01e76) [wt: adjusted context, s/max/LONGBITS] Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit adadecb56f68e173b19b0aa28225812e463d6930) Signed-off-by: Willy Tarreau <[email protected]> commit 109b76f51c282ca51d0b6e6c0c9202e3c50ff1db Author: Willy Tarreau <[email protected]> Date: Sun Feb 10 18:49:37 2019 +0100 BUG/MAJOR: stream: avoid double free on unique_id Commit 32211a1 ("BUG/MEDIUM: stream: Don't forget to free s->unique_id in stream_free().") addressed a memory leak but in exchange may cause double-free due to the fact that after freeing s->unique_id it doesn't null it and then calls http_end_txn() which frees it again. Thus the process quickly crashes at runtime. This fix must be backported to all stable branches where the aforementioned patch was backported. (cherry picked from commit 09c4bab41188c13e7a9227f8baaff230ebdd0875) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 451c5a8879a9d59b489ad5117c984044d41c8338) Signed-off-by: Willy Tarreau <[email protected]> commit 7cd8fc9eb3dfc89ef7c8d7b958f09552b3ccdc9c Author: Christopher Faulet <[email protected]> Date: Thu Feb 7 16:13:26 2019 +0100 BUG/MAJOR: spoe: Don't try to get agent config during SPOP healthcheck During SPOP healthchecks, a dummy appctx is used to create the HAPROXY-HELLO frame and then to parse the AGENT-HELLO frame. No agent are attached to it. So it is important to not rely on an agent during these stages. When HAPROXY-HELLO frame is created, there is no problem, all accesses to an agent are guarded. This is not true during the parsing of the AGENT-HELLO frame. Thus, it is possible to crash HAProxy with a SPOA declaring the async or the pipelining capability during a healthcheck. This patch must be backported to 1.9 and 1.8. (cherry picked from commit 11389018bc92bf7b94533e682af5cb4bbf0e43d9) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 644283b87d183ad3a22c3f3e0145bde8387b4e6e) Signed-off-by: Willy Tarreau <[email protected]> commit a2cf951ac907e6cf89cfd5eee414e29e8cd8422a Author: Willy Tarreau <[email protected]> Date: Thu Feb 7 14:46:29 2019 +0100 BUG/MEDIUM: server: initialize the idle conns list after parsing the config The idle conns lists are sized according to the number of threads. As such they cannot be initialized during the parsing since nbthread can be set later, as revealed by this simple config which randomly crashes when used. Let's do this at the end instead. listen proxy bind :4445 mode http timeout client 10s timeout server 10s timeout connect 10s http-reuse always server s1 127.0.0.1:8000 global nbthread 8 This fix must be backported to 1.9 and 1.8. (cherry picked from commit 835daa119e75a54689375da9c77e5d0e6bd7362f) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 778e19d8bc056531a40e9eaeee4a37aff0037e68) [wt: also update srv->update_status, and s/srv/newsrv as in 980855b] Signed-off-by: Willy Tarreau <[email protected]> commit 419fffe172c438652b06d2be08c70c7876e4f331 Author: Willy Tarreau <[email protected]> Date: Thu Feb 7 13:40:33 2019 +0100 BUG/MEDIUM: spoe: initialization depending on nbthread must be done last The agent used to be configured depending on global.nbthread while nbthread may be set after the agent is parsed. Let's move this part to the spoe_check() function to make sure nbthread is always correct and arrays are appropriately sized. This fix must be backported to 1.9 and 1.8. (cherry picked from commit b0769b2ed668119e024e2fbda79eef46ece8511a) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit ad254a7e9414d0771d2ba9b20a0d5cceb13fbc32) [wt: a few more fields exist in 1.8: applets_act, applets_idle, sending_rate] Signed-off-by: Willy Tarreau <[email protected]> commit c5d303f85a6c5badc65e600a8492e9c89fcc84e7 Author: Willy Tarreau <[email protected]> Date: Thu Feb 7 14:48:24 2019 +0100 BUG/MINOR: lua: initialize the correct idle conn lists for the SSL sockets Commit 40a007cf2 ("MEDIUM: threads/server: Make connection list (priv/idle/safe) thread-safe") made a copy-paste error when initializing the Lua sockets, as the TCP one was initialized twice. Fortunately it has no impact because the pointers are set to NULL after a memset(0) and are not changed in between. This must be backported to 1.9 and 1.8. (cherry picked from commit b784b35ce88842c3b7630085775fdd6e5f858bc8) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit d10cdf434721a3f5f2453f60d544a56dcf426d66) Signed-off-by: Willy Tarreau <[email protected]> commit 3abc8d3c90e7726b0772ee8e700e68620cd01490 Author: Willy Tarreau <[email protected]> Date: Thu Feb 7 14:22:52 2019 +0100 BUG/MINOR: spoe: do not assume agent->rt is valid on exit As reported by Christopher, we may call spoe_release_agent() when leaving after an allocation failure or a config parse error. We must not assume agent->rt is valid there as the allocation could have failed. This should be backported to 1.9 and 1.8. (cherry picked from commit 3ddcf7643cfe5b542d72b0f6f815fc302e8e3bc9) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit c4b91f291015dc39a7a953df41a13c2c452b50bc) Signed-off-by: Willy Tarreau <[email protected]> commit 7410f366b258d44ac8e31290aff8e781cf1d4179 Author: Bertrand Jacquin <[email protected]> Date: Sun Feb 3 18:48:49 2019 +0000 DOC: ssl: Stop documenting ciphers example to use Since TLS ciphers are not well understand, it is very common pratice to copy and paste parameters from documentation and use them as-is. Since RC4 should not be used anymore, it is wiser to link users to up to date documnetation from Mozilla to avoid unsafe configuration in the wild. Clarify the location of man pages for OpenSSL when missing. (cherry picked from commit 4f03ab06a90df8e88ba2e347f52465b31392acc4) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 72a3f9a0beaf821a27e2fe36ac8e035cf3713133) Signed-off-by: Willy Tarreau <[email protected]> commit 625aa784efe0641d6efd7202301b70ac54771024 Author: Bertrand Jacquin <[email protected]> Date: Sun Feb 3 18:35:25 2019 +0000 DOC: ssl: Clarify when pre TLSv1.3 cipher can be used This is mainly driven by the fact TLSv1.3 will have a successor at some point. (cherry picked from commit 8cf7c1eb6123bce935f592844a4638d74b462aae) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit feb20b8764524c230c5fb4c364f2341b70129e88) Signed-off-by: Willy Tarreau <[email protected]> commit 75ee9fca192ee28b13ba81aa9e956c84b8b4c61d Author: Willy Tarreau <[email protected]> Date: Wed Feb 6 15:31:22 2019 +0100 [RELEASE] Released version 1.8.18 Released version 1.8.18 with the following main changes : - DOC: http-request cache-use / http-response cache-store expects cache name - BUG/MAJOR: cache: fix confusion between zero and uninitialized cache key - BUG/MEDIUM: ssl: Disable anti-replay protection and set max data with 0RTT. - DOC: Be a bit more explicit about allow-0rtt security implications. - BUG/MEDIUM: ssl: missing allocation failure checks loading tls key file - BUG/MINOR: backend: don't use url_param_name as a hint for BE_LB_ALGO_PH - BUG/MINOR: backend: balance uri specific options were lost across defaults - BUG/MINOR: backend: BE_LB_LKUP_CHTREE is a value, not a bit - BUG/MINOR: stick_table: Prevent conn_cur from underflowing - BUG/MINOR: server: don't always trust srv_check_health when loading a server state - BUG/MINOR: check: Wake the check task if the check is finished in wake_srv_chk() - BUG/MEDIUM: ssl: Fix handling of TLS 1.3 KeyUpdate messages - DOC: mention the effect of nf_conntrack_tcp_loose on src/dst - MINOR: h2: add a bit-based frame type representation - MINOR: h2: declare new sets of frame types - BUG/MINOR: mux-h2: CONTINUATION in closed state must always return GOAWAY - BUG/MINOR: mux-h2: headers-type frames in HREM are always a connection error - BUG/MINOR: mux-h2: make it possible to set the error code on an already closed stream - BUG/MINOR: hpack: return a compression error on invalid table size updates - DOC: nbthread is no longer experimental. - BUG/MINOR: spoe: corrected fragmentation string size - BUG/MINOR: deinit: tcp_rep.inspect_rules not deinit, add to deinit - SCRIPTS: add the slack channel URL to the announce script - SCRIPTS: add the issue tracker URL to the announce script - BUG/MINOR: stream: don't close the front connection when facing a backend error - MINOR: xref: Add missing barriers. - BUG/MEDIUM: mux-h2: wake up flow-controlled streams on initial window update - BUG/MEDIUM: mux-h2: fix two half-closed to closed transitions - BUG/MEDIUM: mux-h2: make sure never to send GOAWAY on too old streams - BUG/MEDIUM: mux-h2: wait for the mux buffer to be empty before closing the connection - MINOR: stream-int: expand the flags to 32-bit - MINOR: stream-int: add a new flag to mention that we want the connection to be killed - MINOR: connstream: have a new flag CS_FL_KILL_CONN to kill a connection - BUG/MEDIUM: mux-h2: do not close the connection on aborted streams - BUG/MEDIUM: stream: Don't forget to free s->unique_id in stream_free(). - BUG/MINOR: config: fix bind line thread mask validation - BUG/MAJOR: config: verify that targets of track-sc and stick rules are present - BUG/MAJOR: spoe: verify that backends used by SPOE cover all their callers' processes - BUG/MINOR: config: make sure to count the error on incorrect track-sc/stick rules commit e50b9b2bd00b89e99ac9e5253eb23634336ffead Author: Willy Tarreau <[email protected]> Date: Wed Feb 6 10:25:07 2019 +0100 BUG/MINOR: config: make sure to count the error on incorrect track-sc/stick rules When commit 151e1ca98 ("BUG/MAJOR: config: verify that targets of track-sc and stick rules are present") added a check for some process inconsistencies between rules and their stick tables, some errors resulted in a "return 0" statement, which is taken as "no error" in some cases. Let's fix this. This must be backported to all versions using the above commit. (cherry picked from commit 1a0fe3becd99d7860b4eeaccec407325d5a8b8c2) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 6981c190b6aea3d11eadadfd48b2a1fde05e232e) Signed-off-by: Willy Tarreau <[email protected]> commit 4f256797faf9bedb890e1aab3b592af3f0dd8948 Author: Willy Tarreau <[email protected]> Date: Tue Feb 5 13:37:19 2019 +0100 BUG/MAJOR: spoe: verify that backends used by SPOE cover all their callers' processes When a filter is installed on a proxy and references spoe, we must be absolutely certain that the whole chain is valid on a given process when running in multi-process mode. The problem here is that if a proxy 1 runs on process 1, referencing an SPOE agent itself based on a backend running on process 2, this last one will be completely deinited on process 1, and will thus cause random crashes when it gets messages from this proess. This patch makes sure that the whole chain is valid on all of the caller's processes. This fix must be backported to all spoe-enabled maintained versions. It may potentially disrupt configurations which already randomly crash. There hardly is any intermediary solution though, such configurations need to be fixed. (cherry picked from commit 2bdcfde4260ac9115b8a0b7aa916975799273ea9) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit b54a86df6f12ac82614921a8c0d4078d781b1ea7) Signed-off-by: Willy Tarreau <[email protected]> commit a7f9b5545e13a9222e4912fd746f61336e43806d Author: Willy Tarreau <[email protected]> Date: Tue Feb 5 11:38:38 2019 +0100 BUG/MAJOR: config: verify that targets of track-sc and stick rules are present Stick and track-sc rules may optionally designate a table in a different proxy. In this case, a number of verifications are made such as validating that this proxy actually exists. However, in multi-process mode, the target table might indeed exist but not be bound to the set of processes the rules will execute on. This will definitely result in a random behaviour especially if these tables do require peer synchronization, because some tasks will be started to try to synchronize form uninitialized areas. The typical issue looks like this : peers my-peers peer foo ... listen proxy bind-process 1 stick on src table ip ... backend ip bind-process 2 stick-table type ip size 1k peers my-peers While it appears obvious that the example above will not work, there are less obvious situations, such as having bind-process in a defaults section and having a larger set of processes for the referencing proxy than the referenced one. The present patch adds checks for such situations by verifying that all processes from the referencing proxy are present on the other one in all track-sc* and stick-* rules, and in sample fetch / converters referencing another table so that sc_inc_gpc0() and similar are safe as well. This fix must be backported to all maintained versions. It may potentially disrupt configurations which already randomly crash. There hardly is any intermediary solution though, such configurations need to be fixed. (cherry picked from commit 151e1ca989968f5092baa593efd9f485e4947d17) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit c294490c4c977e9c1202ef76b2e0449a038caaa1) Signed-off-by: Willy Tarreau <[email protected]> commit 4672f5920df461278985aed3e4b70f26fdf61d09 Author: Willy Tarreau <[email protected]> Date: Sat Feb 2 17:46:24 2019 +0100 BUG/MINOR: config: fix bind line thread mask validation When no nbproc is specified, a computation leads to reading bind_thread[-1] before checking if the thread mask is valid for a bind conf. It may either report a false warning and compute a wrong mask, or miss some incorrect configs. This must be backported to 1.9 and possibly 1.8. (cherry picked from commit 6b4a39adc4f9f21dec00a118128f179ade698b17) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 2116028dd441165058fc1e89c2914c5c181c5723) Signed-off-by: Willy Tarreau <[email protected]> commit 56fd8658819e504782e0580443ebcd351c5414c3 Author: Olivier Houchard <[email protected]> Date: Fri Feb 1 18:10:46 2019 +0100 BUG/MEDIUM: stream: Don't forget to free s->unique_id in stream_free(). In stream_free(), free s->unique_id. We may still have one, because it's allocated in log.c::strm_log() no matter what, even if it's a TCP connection and thus it won't get free'd by http_end_txn(). Failure to do so leads to a memory leak. This should probably be backported to all maintained branches. (cherry picked from commit 32211a17eb1f1a18d960ec2a451992a928aaaf95) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit f49cc4bfbcd052e6dd448a564e3cd9505ae3fbae) Signed-off-by: Willy Tarreau <[email protected]> commit b1e0f0f4c1c5d9066bfa06347f33d7891615fbdc Author: Willy Tarreau <[email protected]> Date: Thu Jan 31 19:12:48 2019 +0100 BUG/MEDIUM: mux-h2: do not close the connection on aborted streams We used to rely on a hint that a shutw() or shutr() without data is an indication that the upper layer had performed a tcp-request content reject and really wanted to kill the connection, but sadly there is another situation where this happens, which is failed keep-alive request to a server. In this case the upper layer stream silently closes to let the client retry. In our case this had the side effect of killing all the connection. Instead of relying on such hints, let's address the problem differently and rely on information passed by the upper layers about the intent to kill the connection. During shutr/shutw, this is detected because the flag CS_FL_KILL_CONN is set on the connstream. Then only in this case we send a GOAWAY(ENHANCE_YOUR_CALM), otherwise we only send the reset. This makes sure that failed backend requests only fail frontend requests and not the whole connections anymore. This fix relies on the two previous patches adding SI_FL_KILL_CONN and CS_FL_KILL_CONN as well as the fix for the connection close, and it must be backported to 1.9 and 1.8, though the code in 1.8 could slightly differ (cs is always valid) : BUG/MEDIUM: mux-h2: wait for the mux buffer to be empty before closing the connection MINOR: stream-int: add a new flag to mention that we want the connection to be killed MINOR: connstream: have a new flag CS_FL_KILL_CONN to kill a connection (cherry picked from commit 180590409ffd34d4032f89839482ab098aae6f04) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit b147fb2fdcfef423e545cb43afdbe1268874f796) [wt: adjusted context] Signed-off-by: Willy Tarreau <[email protected]> commit 9f7b1f33ab16eadf9d0055ce0e81ef44a7fb569f Author: Willy Tarreau <[email protected]> Date: Thu Jan 31 19:09:59 2019 +0100 MINOR: connstream: have a new flag CS_FL_KILL_CONN to kill a connection This is the equivalent of SI_FL_KILL_CONN but for the connstreams. It will be set by the stream-interface during the various shutdown operations. (cherry picked from commit 51d0a7e54c4d2b1c90cc182a022f3635ac0ebf1c) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit d3ee7806176c4f5ae666ae1d5d197a364e191033) [wt: adjusted flag value] Signed-off-by: Willy Tarreau <[email protected]> commit fa276b2432de18cde3c12dbf5f8fc550296a8de2 Author: Willy Tarreau <[email protected]> Date: Thu Jan 31 19:02:43 2019 +0100 MINOR: stream-int: add a new flag to mention that we want the connection to be killed The new flag SI_FL_KILL_CONN is now set by the rare actions which deliberately want the whole connection (and not just the stream) to be killed. This is only used for "tcp-request content reject", "tcp-response content reject", "tcp-response content close" and "http-request reject". The purpose is to desambiguate the close from a regular shutdown. This will be used by the next patches. (cherry picked from commit 0f9cd7b196073f6d3a3826049b985edcd20c18be) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 3c297e2b0d5f7b88ce7b5b476649e7b2c3bd839c) [wt: adjusted context; http code in proto_http, not http_act] Signed-off-by: Willy Tarreau <[email protected]> commit 5f08f61e72828456507788582a937f9e93060e24 Author: Willy Tarreau <[email protected]> Date: Wed Nov 14 10:53:42 2018 +0100 MINOR: stream-int: expand the flags to 32-bit We used to have enough of 16 bits, with 3 still available but it's not possible to add the rx/tx blocking bits there. Let's extend the format to 32 bits and slightly reorder the fields to maintain the struct size to 64 bytes. Nothing else was changed. (cherry picked from commit a44e576f62d68d937fefff4004b8d5631ede4f15) [wt: needed for the next fixes] Signed-off-by: Willy Tarreau <[email protected]> commit 334191b95a18423227c42bc68992025ec724dcab Author: Willy Tarreau <[email protected]> Date: Thu Jan 31 18:48:20 2019 +0100 BUG/MEDIUM: mux-h2: wait for the mux buffer to be empty before closing the connection When finishing to respond on a stream, a shutw() is called (resulting in either an end of stream or RST), then h2_detach() is called, and may decide to kill the connection is a number of conditions are satisfied. Actually one of these conditions is that a GOAWAY frame was already sent or attempted to be sent. This one is wrong, because it can happen in at least these two situations : - a shutw() sends a GOAWAY to obey tcp-request content reject - a graceful shutdown is pending In both cases, the connection will be aborted with the mux buffer holding some data. In case of a strong abort the client will not see the GOAWAY or RST and might want to try again, which is counter-productive. In case of the graceful shutdown, it could result in truncated data. It looks like a valid candidate for the issue reported here : https://www.mail-archive.com/[email protected]/msg32433.html A backport to 1.9 and 1.8 is necessary. (cherry picked from commit 4dbda620f2872b33aefc8c87ac34f7c71dbd1701) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit ddc68d3cc6a6ce8b4b4ac1853252701c1d984059) [wt: adjusted context] Signed-off-by: Willy Tarreau <[email protected]> commit e57bb019b1ee3d902aa530caaa7b8f1b27b38cb0 Author: Willy Tarreau <[email protected]> Date: Wed Jan 30 19:20:09 2019 +0100 BUG/MEDIUM: mux-h2: make sure never to send GOAWAY on too old streams The H2 spec requires to send GOAWAY when the client sends a frame after it has already closed using END_STREAM. Here the corresponding case was the fallback of a series of tests on the stream state, but it unfortunately also catches old closed streams which we don't know anymore. Thus any late packet after we've sent an RST_STREAM will trigger this GOAWAY and break other streams on the connection. This can happen when launching two tabs in a browser targetting the same slow page through an H2-to-H2 proxy, and pressing Escape to stop one of them. The other one gets an error when the page finally responds (and it generally retries), and the logs in the middle indicate SD-- flags since the late response was cancelled. This patch takes care to only send GOAWAY on streams we still know. It must be backported to 1.9 and 1.8. (cherry picked from commit 24ff1f834151727cb107995b72a72e9992fd8159) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 27a97e1ac0aadf453fde1811b4a84ca91e3a5847) Signed-off-by: Willy Tarreau <[email protected]> commit 899c2f6d518c51524a5c5780439eceab9216769c Author: Willy Tarreau <[email protected]> Date: Wed Jan 30 19:28:32 2019 +0100 BUG/MEDIUM: mux-h2: fix two half-closed to closed transitions When receiving a HEADERS or DATA frame with END_STREAM set, we would inconditionally switch to half-closed(remote). This is wrong because we could already have been in half-closed(local) and need to switch to closed. This happens in the following situations : - receipt of the end of a client upload after we've already responded (e.g. redirects to POST requests) - receipt of a response on the backend side after we've already finished sending the request (most common case). This may possibly have caused some streams to stay longer than needed at the end of a transfer, though this is not apparent in tests. This must be backported to 1.9 and 1.8. (cherry picked from commit fc10f599cc5e5606c15be4828848e04ed2c70f9c) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 29922e39eae8e13d3eb7db64b34e6ea1abd90284) [wt: in 1.8 only the DATA frames were affected, for headers we could not be in anything but OPEN first] Signed-off-by: Willy Tarreau <[email protected]> commit e16779d6e77e24306e210c66e85e113173ad8a6f Author: Willy Tarreau <[email protected]> Date: Wed Jan 30 16:11:20 2019 +0100 BUG/MEDIUM: mux-h2: wake up flow-controlled streams on initial window update When a settings frame updates the initial window, all affected streams's window is updated as well. However the streams are not put back into the send list if they were already blocked on flow control. The effect is that such a stream will only be woken up by a WINDOW_UPDATE message but not by a SETTINGS changing the initial window size. This can be verified with h2spec's test http2/6.9.2/1 which occasionally fails without this patch. It is unclear whether this situation is really met in field, but the fix is trivial, it consists in adding each unblocked streams to the wait list as is done for the window updates. This fix must be backported to 1.9. For 1.8 the patch needs quite a few adaptations. It's better to copy-paste the code block from h2c_handle_window_update() adding the stream to the send_list when its mws is > 0. (cherry picked from commit b1c9edc579aedd608107c4693c17160474b5ae62) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit d195a9c7e877423106c315d23184b47f4d30971c) [wt: adapted according to description] Signed-off-by: Willy Tarreau <[email protected]> commit 5c63f7dd25d80dcdf34ebbae4178e550ede036be Author: Olivier Houchard <[email protected]> Date: Fri Jan 18 17:21:32 2019 +0100 MINOR: xref: Add missing barriers. Add a few missing barriers in the xref code, it's unlikely to be a problem for x86, but may be on architectures with weak memory ordering. (cherry picked from commit ff5dd74e25e1069d74635dba9e8215a6093c481e) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 7fb71841f7b07f3079ee98fd204b23587939c1d5) Signed-off-by: Willy Tarreau <[email protected]> commit ec70cf52e9ef8f86f932bcfbfc4c1dd01bb6ad5e Author: Willy Tarreau <[email protected]> Date: Thu Jan 31 18:58:06 2019 +0100 BUG/MINOR: stream: don't close the front connection when facing a backend error In 1.5-dev13, a bug was introduced by commit e3224e870 ("BUG/MINOR: session: ensure that we don't retry connection if some data were sent"). If a connection error is reported after some data were sent (and lost), we used to accidently mark the front connection as being in error instead of only the back one because the two direction flags were applied to the same channel. This case is extremely rare with raw connections but can happen a bit more often with multiplexed streams. This will result in the error not being correctly reported to the client. This patch can be backported to all supported versions. (cherry picked from commit 28e581b21c8229aa50b7e45148dd46fa6f43da5e) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 9fae3fc9ba6612180b84a5deb27c5ddee7ac366e) Signed-off-by: Willy Tarreau <[email protected]> commit 09e83d2d8c0cb046b561ef826012b5ee6077c409 Author: Willy Tarreau <[email protected]> Date: Tue Jan 29 06:51:16 2019 +0100 SCRIPTS: add the issue tracker URL to the announce script This way it's easier for users to follow the status of pending issues with each release. (cherry picked from commit 9589c3bce78a28fc75978b26168e912455d2b525) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit e68c1ed442d7294968af061ddac8caf8b6601547) Signed-off-by: Willy Tarreau <[email protected]> commit 7f8ca01af0055a21d954025a65bb9f51c0d217b4 Author: Willy Tarreau <[email protected]> Date: Wed Dec 19 18:59:51 2018 +0100 SCRIPTS: add the slack channel URL to the announce script It's just to provide the URL in the usual URLs when releasing. (cherry picked from commit d6cad12d1aa4786fcb4f6003df3e9593d7e34c19) Signed-off-by: Willy Tarreau <[email protected]> commit b7b08a3d30fc8037a72619da1bb9c902678797a1 Author: Kevin Zhu <[email protected]> Date: Wed Jan 30 16:01:21 2019 +0800 BUG/MINOR: deinit: tcp_rep.inspect_rules not deinit, add to deinit It seems like this can be backported as far as 1.5. (cherry picked from commit 13ebef7ecb94168039241bce66c2bdc0a3789c16) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit c6358e374dd040c6b4bc5e6d6933f2b9a1b213d2) Signed-off-by: Willy Tarreau <[email protected]> commit 57cd186404695078fba61c7c4ffae0eaddb553f4 Author: Miroslav Zagorac <[email protected]> Date: Sun Jan 13 16:55:01 2019 +0100 BUG/MINOR: spoe: corrected fragmentation string size This patch must be backported to 1.9 and 1.8. (cherry picked from commit 6b3690bc6ae44c60677d55c6a82b459f76b91e30) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit eac5bea548dd07d82af12ef91f47a2e908e52bd7) [wt: adjusted to new buffer API] Signed-off-by: Willy Tarreau <[email protected]> commit f97ec4633e8a7d9a795ccf0c8d404139023d5f53 Author: Willy Tarreau <[email protected]> Date: Sat Jan 26 14:20:55 2019 +0100 DOC: nbthread is no longer experimental. It was mentioned when releasing 1.8 but early bugs have long been addressed and this comment discourages some users from using threads. This should be backported to 1.9 and 1.8 now. (cherry picked from commit 1f672a8162eda18c404c6784dd749b6e061e2e4d) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 227f473d78d2cacdc01fdab80b9bc337753ec4c0) Signed-off-by: Willy Tarreau <[email protected]> commit e264e9aa25c044221ab109777f4ce7f46064347a Author: Willy Tarreau <[email protected]> Date: Thu Jan 24 10:47:10 2019 +0100 BUG/MINOR: hpack: return a compression error on invalid table size updates RFC7541#6.3 mandates that an error is reported when a dynamic table size update announces a size larger than the one configured with settings. This is tested by h2spec using test "hpack/6.3/1". This must be backported to 1.9 and possibly 1.8 as well. (cherry picked from commit 1e7d444eec69db192d026a542262891b8de89e0c) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 012a14fe6aa2b3ef42a6677a60fa97870968c938) [wt: adjusted context] Signed-off-by: Willy Tarreau <[email protected]> commit dccc35ba3573af267c5316784859ae39b83c7b3e Author: Willy Tarreau <[email protected]> Date: Thu Jan 24 10:02:24 2019 +0100 BUG/MINOR: mux-h2: make it possible to set the error code on an already closed stream When sending RST_STREAM in response to a frame delivered on an already closed stream, we used not to be able to update the error code and deliver an RST_STREAM with a wrong code (e.g. H2_ERR_CANCEL). Let's always allow to update the code so that RST_STREAM is always sent with the appropriate error code (most often H2_ERR_STREAM_CLOSED). This should be backported to 1.9 and possibly to 1.8. (cherry picked from commit 175cebb38ad7e06ae207ab947b02a344660f981b) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit e199e526a943a5d25fc321308df81b3ac9e70109) [wt: adjusted context. id==0 is OK here as well] Signed-off-by: Willy Tarreau <[email protected]> commit 2d18a33b439c9ff95dd9ece67aeef6d23ad073d2 Author: Willy Tarreau <[email protected]> Date: Thu Jan 24 09:43:32 2019 +0100 BUG/MINOR: mux-h2: headers-type frames in HREM are always a connection error There are incompatible MUST statements in the HTTP/2 specification. Some require a stream error and others a connection error for the same situation. As discussed in the thread below, let's always apply the connection error when relevant (headers-like frame in half-closed(remote)) : https://mailarchive.ietf.org/arch/msg/httpbisa/pOIWRBRBdQrw5TDHODZXp8iblcE This must be backported to 1.9, possibly to 1.8 as well. (cherry picked from commit 5b4eae33dee01224f0ece9db0891ca7a1fb2805d) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 9db8619e1f7f67cbad46d4c5bee33a9dd4c0d3b6) Signed-off-by: Willy Tarreau <[email protected]> commit d3cbaa592d49aa85c64fd8c8b5a0d71ea2517fd4 Author: Willy Tarreau <[email protected]> Date: Thu Jan 24 09:36:53 2019 +0100 BUG/MINOR: mux-h2: CONTINUATION in closed state must always return GOAWAY Since we now support CONTINUATION frames, we must take care of properly aborting the connection when they are sent on a closed stream. By default we'd get a stream error which is not sufficient since the compression context is modified and unrecoverable. More info in this discussion : https://mailarchive.ietf.org/arch/msg/httpbisa/azZ1jiOkvM3xrpH4jX-Q72KoH00 This needs to be backported to 1.9 and possibly to 1.8 (less important there). (cherry picked from commit 113c7a2794a86e658faf80b000a5d849f30e299e) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit eeac5e76b582cc72864cbd2540925b1ac3b72807) Signed-off-by: Willy Tarreau <[email protected]> commit 81981189761dc8a9708af21f3b60f3a74b6d5901 Author: Willy Tarreau <[email protected]> Date: Thu Jan 24 09:31:40 2019 +0100 MINOR: h2: declare new sets of frame types This patch adds H2_FT_HDR_MASK to group all frame types carrying headers information, and H2_FT_LATE_MASK to group frame types allowed to arrive after a stream was closed. (cherry picked from commit 71c3811589b2e8d8e28f91c7e47bd05594a739ab) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 0ec0583ce38cca41ae06384d7960b338eac6a84e) Signed-off-by: Willy Tarreau <[email protected]> commit 7c84b83f4d1e4be861874fb2f18ba245cca18cc8 Author: Willy Tarreau <[email protected]> Date: Fri Dec 21 14:56:57 2018 +0100 MINOR: h2: add a bit-based frame type representation This will ease checks among sets of frames. (cherry picked from commit deab244dc150032e1c57368289391af73c0b8aee) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 53f59371852419247083aac450e087485a2f5889) Signed-off-by: Willy Tarreau <[email protected]> commit 2e405726a0c6be6617905522bde9038f75e623c4 Author: Willy Tarreau <[email protected]> Date: Wed Jan 23 10:02:15 2019 +0100 DOC: mention the effect of nf_conntrack_tcp_loose on src/dst On rare occasions the logs may report inverted src/dst when using conntrack with this sysctl. Add a mention for it in the doc. More info here : https://www.spinics.net/lists/netdev/msg544878.html (cherry picked from commit 64ded3db2c686bad582cf9bb9fcabf21cb4becb7) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 037f9ac4a2cc4b344859af1cff7b30d5ecabe9e0) Signed-off-by: William Lallemand <[email protected]> commit b68a427a236e7b9b0cf8b1c4a5360d960cdf9458 Author: Dirkjan Bussink <[email protected]> Date: Mon Jan 21 09:35:03 2019 -0800 BUG/MEDIUM: ssl: Fix handling of TLS 1.3 KeyUpdate messages In OpenSSL 1.1.1 TLS 1.3 KeyUpdate messages will trigger the callback that is used to verify renegotiation is disabled. This means that these KeyUpdate messages fail. In OpenSSL 1.1.1 a better mechanism is available with the SSL_OP_NO_RENEGOTIATION flag that disables any TLS 1.2 and earlier negotiation. So if this SSL_OP_NO_RENEGOTIATION flag is available, instead of having a manual check, trust OpenSSL and disable the check. This means that TLS 1.3 KeyUpdate messages will work properly. Reported-By: Adam Langley <[email protected]> (cherry picked from commit 526894ff3925d272c13e57926aa6b5d9d8ed5ee3) [wt: gh issue #24; Needs to be backported till 1.8] Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 062c5a190d50c4aa9c5bde88c8c5c85c5f15fc7b) Signed-off-by: William Lallemand <[email protected]> commit 7a74ffef9f356304b46ab862858cead85d451b5f Author: Christopher Faulet <[email protected]> Date: Mon Jan 21 14:15:50 2019 +0100 BUG/MINOR: check: Wake the check task if the check is finished in wake_srv_chk() With tcp-check, the result of the check is set by the function tcpcheck_main() from the I/O layer. So it is important to wake up the check task to handle the result and finish the check. Otherwise, we will wait the task timeout to handle the result of a tcp-check, delaying the next check by as much. This patch also fixes a problem about email alerts reported by PiBa-NL (Pieter) on the ML [1] on all versions since the 1.6. So this patch must be backported from 1.9 to 1.6. [1] https://www.mail-archive.com/[email protected]/msg32190.html (cherry picked from commit 774c486cece942570b6a9d16afe236a16ee12079) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 3722dfbbfadf8f83f82feb3e67fbe482a5c94840) Signed-off-by: William Lallemand <[email protected]> commit 1c95076d881b7508a8d0819b1cfd642e364b255c Author: Jérôme Magnin <[email protected]> Date: Sun Jan 20 11:27:40 2019 +0100 BUG/MINOR: server: don't always trust srv_check_health when loading a server state When we load health values from a server state file, make sure what we assign to srv->check.health actually matches the state we restore. This should be backported as far as 1.6. (cherry picked from commit f57afa453a685cfd92b7a27ef6e6035cb384ff57) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 75455a0b78ce4ac723698df26c014b38467843b1) Signed-off-by: William Lallemand <[email protected]> commit 93b3994091b5bd17b43c9d91ecae470d33157e25 Author: Tim Duesterhus <[email protected]> Date: Fri Jan 4 00:11:59 2019 +0100 BUG/MINOR: stick_table: Prevent conn_cur from underflowing When using the peers feature a race condition could prevent a connection from being properly counted. When this connection exits it is being "uncounted" nonetheless, leading to a possible underflow (-1) of the conn_curr stick table entry in the following scenario : - Connect to peer A (A=1, B=0) - Peer A sends 1 to B (A=1, B=1) - Kill connection to A (A=0, B=1) - Connect to peer B (A=0, B=2) - Peer A sends 0 to B (A=0, B=0) - Peer B sends 0/2 to A (A=?, B=0) - Kill connection to B (A=?, B=-1) - Peer B sends -1 to A (A=-1, B=-1) This fix may be backported to all supported branches. (cherry picked from commit 8b87c01c4d59247d9fb51a38cd12d5d94324b6a4) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 4ceecc8a4ee6f46f20c7729056e14af5a8757121) Signed-off-by: William Lallemand <[email protected]> commit 7c6a6149a91d2e240a5a63f981c5d07d681df725 Author: Willy Tarreau <[email protected]> Date: Mon Jan 14 17:07:39 2019 +0100 BUG/MINOR: backend: BE_LB_LKUP_CHTREE is a value, not a bit There are a few instances where the lookup algo is tested against BE_LB_LKUP_CHTREE using a binary "AND" operation while this macro is a value among a set, and not a bit. The test happens to work because the value is exactly 4 and no bit overlaps with the other possible values but this is a latent bug waiting for a new LB algo to appear to strike. At the moment the only other algo sharing a bit with it is the "first" algo which is never supported in the same code places. This fix should be backported to maintained versions for safety if it passes easily, otherwise it's not important as it will not fix any visible issue. (cherry picked from commit 6c30be52da3d949a8dd6fb5e2de7319c031e656e) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 48147c424680b7e887fb176662d58d87baa16098) Signed-off-by: William Lallemand <[email protected]> commit a5027f804144536f79829443b33e6c19c32b690a Author: Willy Tarreau <[email protected]> Date: Mon Jan 14 16:29:52 2019 +0100 BUG/MINOR: backend: balance uri specific options were lost across defaults The "balance uri" options "whole", "len" and "depth" were not properly inherited from the defaults sections. In addition, "whole" and "len" were not even reset when parsing "uri", meaning that 2 subsequent "balance uri" statements would not have the expected effect as the options from the first one would remain for the second one. This may be backported to all maintained versions. (cherry picked from commit 602a499da5e81d6b4cfe8410f0fc6d53c1e06745) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit f00758fde5961e3bebc508852faeee4d9d80b0e0) [wla: cfg_parse_listen() is still in cfgparse.c in 1.8] Signed-off-by: William Lallemand <[email protected]> commit 98f9549fa466e3b73a04f17dbc05fd88427c72f4 Author: Willy Tarreau <[email protected]> Date: Mon Jan 14 15:17:46 2019 +0100 BUG/MINOR: backend: don't use url_param_name as a hint for BE_LB_ALGO_PH At a few places in the code we used to rely on this variable to guess what LB algo was in place. This is wrong because if the defaults section presets "balance url_param foo" and a backend uses "balance roundrobin", these locations will still see this url_param_name set and consider it. The harm is limited, as this only causes the beginning of the request body to be buffered. And in general this is a bad practice which prevents us from cleaning the lbprm stuff. Let's explicitly check the LB algo instead. This may be backported to all currently maintained versions. (cherry picked from commit 089eaa0ba73913187e93d52c3ea34faa01fd8f9c) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 70d1744bb41daab4110071e4855504b6dc47bda9) [wla: no htx in 1.8] Signed-off-by: William Lallemand <[email protected]> commit 30cd01cbfd40201f3abe246216a85c69352aa79c Author: Emeric Brun <[email protected]> Date: Thu Jan 10 10:51:13 2019 +0100 BUG/MEDIUM: ssl: missing allocation failure checks loading tls key file This patch fixes missing allocation checks loading tls key file and avoid memory leak in some error cases. This patch should be backport on branches 1.9 and 1.8 (cherry picked from commit 09852f70e0ed0f23cf9287b1ce55bb6a60112f32) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit a1dc55a63cfbc8f440b72b6def3957bf1fad12b2) Signed-off-by: William Lallemand <[email protected]> commit aca7e5aed7e036489ccc83d925103e94653b8670 Author: Olivier Houchard <[email protected]> Date: Tue Jan 8 15:35:32 2019 +0100 DOC: Be a bit more explicit about allow-0rtt security implications. Document a bit better than allow-0rtt can trivially be used for replay attacks, and so should only be used when it's safe to replay a request. This should probably be backported to 1.8 and 1.9. (cherry picked from commit 69752964944ef9c8dc03477ee95bc7d149a72089) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit bb0df71201ad5b2d0cec514773d244275e5240df) Signed-off-by: William Lallemand <[email protected]> commit 9f01534cd68de78c74b50d7b8def07a72c2a3b49 Author: Olivier Houchard <[email protected]> Date: Wed Jan 2 18:46:41 2019 +0100 BUG/MEDIUM: ssl: Disable anti-replay protection and set max data with 0RTT. When using early data, disable the OpenSSL anti-replay protection, and set the max amount of early data we're ready to accept, based on the size of buffers, or early data won't work with the released OpenSSL 1.1.1. This should be backported to 1.8. (cherry picked from commit 51088ce68fee0bae52118d6823873417046f9efe) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 6703b633078b6bae12395ee3e310427b37965d68) Signed-off-by: William Lallemand <[email protected]> commit a64e5574e40e3e0819c82e35a7e3d2fa65febc73 Author: Willy Tarreau <[email protected]> Date: Fri Jan 11 19:38:25 2019 +0100 BUG/MAJOR: cache: fix confusion between zero and uninitialized cache key The cache uses the first 32 bits of the uri's hash as the key to reference the object in the cache. It makes a special case of the value zero to mean that the object is not in the cache anymore. The problem is that when an object hashes as zero, it's still inserted but the eb32_delete() call is skipped, resulting in the object still being chained in the memory area while the block has been reclaimed and used for something else. Then when objects which were chained below it (techically any object since zero is at the root) are deleted, the walk through the upper object may encounter corrupted values where valid pointers were expected. But while this should only happen statically once on 4 billion, the problem gets worse when the cache-use conditions don't match the cache-store ones, because cache-store runs with an uninitialized key, which can create objects that will never be found by the lookup code, or worse, entries with a zero key preventing eviction of the tree node and resulting in a crash. It's easy to accidently end up on such a config because the request rules generally can't be used to decide on the response : http-request cache-use cache if { path_beg /images } http-response cache-store cache In this test, mixing traffic with /images/$RANDOM and /foo/$RANDOM will result in random keys being inserted, some of them possibly being zero, and crashes will quickly happen. The fix consists in 1) always initializing the transaction's cache_hash to zero, and 2) never storing a response for which the hash has not been calculated, as indicated by the value zero. It is worth noting that objects hashing as value zero will never be cached, but given that there's only one chance among 4 billion that this happens, this is totally harmless. This fix must be backported to 1.9 and 1.8. (cherry picked from commit c9036c00044a8d81561113886ecec9a9ce71bd3b) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 5a6279fcc16da479304bcabc1705e8653f274337) Signed-off-by: William Lallemand <[email protected]> commit 6648ff0cccee04a6a0c0e64050151b5d6c5bac51 Author: Jarno Huuskonen <[email protected]> Date: Fri Jan 4 14:05:02 2019 +0200 DOC: http-request cache-use / http-response cache-store expects cache name Adds missing cache name option to http-request cache-use and http-response cache-store documentation. Also adds optional if/unless condition to 10.2.2. Proxy section: http-request cache-use / http-response cache-store (cherry picked from commit 251a6b72a8b6f0a4b167f6a2960e422d682aed80) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 5376f6af9239fdf8a79b6c912387de12e3c9d6cd) [wla: no http-request/response section in 1.8] Signed-off-by: William Lallemand <[email protected]> commit e89d25b22da1eefa88ef5aa8ad6fa21e1bd4c801 Author: Willy Tarreau <[email protected]> Date: Tue Jan 8 14:11:02 2019 +0100 [RELEASE] Released version 1.8.17 Released version 1.8.17 with the following main changes : - BUG/MAJOR: stream-int: Update the stream expiration date in stream_int_notify() - MINOR: mux-h2: only increase the connection window with the first update - BUG/MEDIUM: mux-h2: mark that we have too many CS once we have more than the max - BUG/MEDIUM: server: Also copy "check-sni" for server templates. - MINOR: lb: allow redispatch when using consistent hash - MINOR: stream/cli: fix the location of the waiting flag in "show sess all" - MINOR: stream/cli: report more info about the HTTP messages on "show sess all" - BUG/MEDIUM: cli: make "show sess" really thread-safe - BUG/MINOR: lua: Return an error if a legacy HTTP applet doesn't send anything - BUG/MINOR: lua: bad args are returned for Lua actions - BUG/MEDIUM: lua: dead lock when Lua tasks are trigerred - BUG/CRITICAL: mux-h2: re-check the frame length when PRIORITY is used commit e1fb3ad02889d8063eace879171cddb7edf477f3 Author: Willy Tarreau <[email protected]> Date: Mon Dec 31 07:41:24 2018 +0100 BUG/CRITICAL: mux-h2: re-check the frame length when PRIORITY is used Tim Düsterhus reported a possible crash in the H2 HEADERS frame decoder when the PRIORITY flag is present. A check is missing to ensure the 5 extra bytes needed with this flag are actually part of the frame. As per RFC7540#4.2, let's return a connection error with code FRAME_SIZE_ERROR. Many thanks to Tim for responsibly reporting this issue with a working config and reproducer. This issue was assigned CVE-2018-20615. This fix must be backported to 1.9 and 1.8. (cherry picked from commit a01f45e3ced23c799f6e78b5efdbd32198a75354) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit ce376ea771ad5484cf0c7559c59e7ea807733df6) Signed-off-by: Willy Tarreau <[email protected]> commit d94c44ef9874040e5809369aaa0648896400dec0 Author: Thierry FOURNIER <[email protected]> Date: Sun Jan 6 19:04:24 2019 +0100 BUG/MEDIUM: lua: dead lock when Lua tasks are trigerred When a task is created from Lua context out of initialisation, the hlua_ctx_init() function can be called from safe environement, so we must not initialise it. While the support of threads appear, the safe environment set a lock to ensure only one Lua execution at a time. If we initialize safe environment in another safe environmenet, we have a dead lock. this patch adds the support of the idicator "already_safe" whoch indicates if the context is initialized form safe Lua fonction. thank to Flakebi for the report This patch must be backported to haproxy-1.9 and haproxy-1.8 (cherry picked from commit bf90ce12aaf71f7a18a1ad63d3a0b6909be97512) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 842cebf77d45664f73f5917cf48c4a062b18a57f) Signed-off-by: Willy Tarreau <[email protected]> commit 174c4a5cf0febef88041faebc6430f66bae4adca Author: Thierry FOURNIER <[email protected]> Date: Sun Jan 6 19:38:49 2019 +0100 BUG/MINOR: lua: bad args are returned for Lua actions In tcp actions case, the argument n - 1 is returned. For example: http-request lua.script stuff display "stuff" as first arg tcp-request content lua.script stuff display "lua.script" as first arg The action parser doesn't use the *cur_arg value. Thanks to Andy Franks for the bug report. This patch mist be backported in haproxy-1.8 and haproxy-1.9 (cherry picked from commit 1725c2e3951d4eeae136125f417c620fa0ed3847) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 10bf073b93422ef32daa0a2c23f708987269a1a3) Signed-off-by: Willy Tarreau <[email protected]> commit e24e5fd2b510b81fb802df41067f36b904420e90 Author: Christopher Faulet <[email protected]> Date: Tue Dec 18 21:20:57 2018 +0100 BUG/MINOR: lua: Return an error if a legacy HTTP applet doesn't send anything In legacy mode, if an HTTP applet does not send any response, an error 500 is returned. (cherry picked from commit cc26b13ea51982edccce7bd5aec7b58f395acd4c) Signed-off-by: Willy Tarreau <[email protected]> commit 4b57858a43dd11c9257b91079f6ce256a6fe38d8 Author: Willy Tarreau <[email protected]> Date: Fri Jan 4 17:42:57 2019 +0100 BUG/MEDIUM: cli: make "show sess" really thread-safe This one used to rely on a few spin locks around lists manipulations only but 1) there were still a few races (e.g. when aborting, or between STAT_ST_INIT and STAT_ST_LIST), and 2) after last commit which dumps htx info it became obvious that dereferencing the buffer contents is not safe at all. This patch uses the thread isolation from the rendez-vous point instead, to guarantee that nothing moves during the dump. It may make the dump a bit slower but it will be 100% safe. This fix must be backported to 1.9, and possibly to 1.8 which likely suffers from the short races above, eventhough they're extremely hard to trigger. (cherry picked from commit e6e52366c185db13ccaf0d2d669909c157d55923) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 53ce8fc062c9a80273698412badb1837290718aa) [wt: s/si_rx_room_blk/si_applet_cant_put/] Signed-off-by: Willy Tarreau <[email protected]> commit 784260e63dbb3a994c046bf65bbf7eedcec296a8 Author: Willy Tarreau <[email protected]> Date: Mon Jan 7 10:38:10 2019 +0100 MINOR: stream/cli: report more info about the HTTP messages on "show sess all" The "show sess all" command didn't allow to detect whether compression is in use for a given stream, which is sometimes annoying. Let's add a few more info about the HTTP messages, namely the flags, body len, chunk len and the "next" pointer. (cherry picked from commit 7778b59be1d444c7e0cb5b2fd6c10d9aa54f773d) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit e9686e78b0e1df98122fe95b8e7129312cdc3bf7) Signed-off-by: Willy Tarreau <[email protected]> commit 6d9b1b7235176d28e12d2c92e97dadd5e31884f5 Author: Willy Tarreau <[email protected]> Date: Mon Jan 7 10:10:07 2019 +0100 MINOR: stream/cli: fix the location of the waiting flag in "show sess all" The "waiting" flag indicates if the stream is waiting for some memory, and was placed on the same output line as the txn for ease of reading. But since 1.6 the txn is not part of the stream anymore so this output was placed under a condition, resulting in "waiting" to appear only when a txn is present. Let's move it upper, closer to the stream's flags to fix this. This may safely be backported though it has little value for older versions. (cherry picked from commit adf7a15bd1d41c45a214410745479e3381ef45de) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit f8b90fb6967d10428ef545ccb277c2013db44394) Signed-off-by: Willy Tarreau <[email protected]> commit 5f768a2eab35e7ac16f49cd2c0b495e3daae2e81 Author: Willy Tarreau <[email protected]> Date: Wed Jan 2 14:48:31 2019 +0100 MINOR: lb: allow redispatch when using consistent hash Redispatch traditionally only worked for cookie based persistence. Adding redispatch support for consistent hash based persistence - also update docs. Reported by Oskar Stenman on discourse: https://discourse.haproxy.org/t/balance-uri-consistent-hashing-redispatch-3-not-redispatching/3344 Should be backported to 1.8. Cc: Lukas Tribus <[email protected]> (cherry picked from commit 59884a646c046411a9080e72d2266ba6a4d4d166) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 97320b5d4147277d0a685fd9c29e4dcf17310769) Signed-off-by: Willy Tarreau <[email protected]> commit 5b9c962725e8352189911f2bdac7e3fa14f73846 Author: Olivier Houchard <[email protected]> Date: Fri Dec 21 19:42:01 2018 +0100 BUG/MEDIUM: server: Also copy "check-sni" for server templates. When using server templates, if "check-sni" is used, make sure it shows up in all the created servers. This should be backported to 1.8 and 1.9. (cherry picked from commit 21944019cabcb46ceb95b7fd925528b9dace4e35) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit c1446f2079d25d9224b1d8b88510ac020c8c47fc) Signed-off-by: Willy Tarreau <[email protected]> commit 384253481ee25dd4bb271f71cd2d47d732926d16 Author: Willy Tarreau <[email protected]> Date: Sun Dec 23 20:43:58 2018 +0100 BUG/MEDIUM: mux-h2: mark that we have too many CS once we have more than the max Since commit f210191 ("BUG/MEDIUM: h2: don't accept new streams if conn_streams are still in excess") we're refraining from reading input frames if we've reached the limit of number of CS. The problem is that it prevents such situations from working fine. The initial purpose was in fact to prevent from reading new HEADERS frames when this happens, and causes some occasional transfer hiccups and pauses with large concurrencies. Given that we now properly reject extraneous streams before checking this value, we can be sure never to have too many streams, and that any higher value is only caused by a scheduling reason and will go down after the scheduler calls the code. This fix must be backported to 1.9 and possibly to 1.8. It may be tested using h2spec this way with an h2spec config : while :; do h2spec -o 5 -v -t -S -k -h 127.0.0.1 -p 4443 http2/5.1.2 done (cherry picked from commit a87546624369ef94546907d90a17da9c985399fd) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit 69a87adfea4090b218d8239de6b81d4376e243fc) Signed-off-by: Willy Tarreau <[email protected]> commit c26ae3e6bd739b5936ba2da2e821064a060f156e Author: Willy Tarreau <[email protected]> Date: Sun Dec 23 09:49:04 2018 +0100 MINOR: mux-h2: only increase the connection window with the first update Commit dc57236 ("BUG/MINOR: mux-h2: advertise a larger connection window size") caused a WINDOW_UPDATE message to be sent early with the connection to increase the connection's window size. It turns out that it causes some minor trouble that need to be worked around : - varnishtest cannot transparently cope with the WU frames during the handshake, forcing all tests to explicitly declare the handshake sequence ; - some vtc scripts randomly fail if the WU frame is sent after another expected response frame, adding uncertainty to some tests ; - h2spec doesn't correctly identify these WU at the connection level that it believes are the responses to some purposely erroneous frames it sends, resulting in some errors being reported None of these are a problem with real clients but they add some confusion during troubleshooting. Since the fix above was intended to increase the upload bandwidth, we have another option which is to increase the window size with the first WU frame sent for the connection. This way, no WU frame is sent until one is really needed, and this first frame will adjust the window to the maximum value. It will make the window increase slightly later, so the client will experience the first round trip when uploading data, but this should not be perceptible, and is not worth the extra hassle needed to maintain our debugging abilities. As an extra bonus, a few extra bytes are saved for each connection until the first attempt to upload data. This should possibly be backported to 1.9 and 1.8. (cherry picked from commit 97aaa6765870d9fd32900ab83d124e58fec6d09b) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit f000410146683dd516e65bd0445e9dfa8b172115) Signed-off-by: Willy Tarreau <[email protected]> commit ca3a8768ddf3766db6b4b9e261c891c7d12ecb09 Author: Christopher Faulet <[email protected]> Date: Thu Jan 3 16:24:54 2019 +0100 BUG/MAJOR: stream-int: Update the stream expiration date in stream_int_notify() Since a long time, the expiration date of a stream is only updated in process_stream(). It is calculated, among others, using the channels expiration dates for reads and writes (.rex and .wex values). But these values are updated by the stream-interface. So when this happens at the connection layer, the update is only done if the stream's task is woken up. Otherwise, the stream expiration date is not immediatly updated. This leads to unexpected behaviours. Time to time, users reported that the wrong timeout was hitted or the wrong termination state was reported. This is partly because of this bug. Recently, we observed some blocked sessions for a while when big objects are served from the cache applet. It seems only concern the clients not reading the response. Because delivered objects are big, not all data can be sent. And because delivered objects are big, data are fast forwarded (from the input to the output with no stream wakeup). So in such situation, the stream expiration date is never updated and no timeout is hitted. The session remains blocked while the client remains connected. This bug exists at least since HAProxy 1.5. But recent changes on the connection layer make it more visible. It must be backported from 1.9 to 1.6. And with more pain it should be backported to 1.5. (cherry picked from commit d7607de06574f00e999434051e082615908939a6) Signed-off-by: Willy Tarreau <[email protected]> (cherry picked from commit dcb673d23ec09af5b4cad93b34b30bc31a3495f4) Signed-off-by: Willy Tarreau <[email protected]> commit 5c3f23783032298a602127e554a5eef0dfdf357e Author: William Lallemand <[email protected]> Date: Fri Dec 21 16:17:53 2018 +0100 [RELEASE] Released version 1.8.16 Released version 1.8.16 with the following main changes : - BUG/MINOR: logs: leave startup-logs global and not per-thread - BUG/MEDIUM: dns: Don't prevent reading the last byte of the payload in dns_validate_response() - BUG/MEDIUM: dns: overflowed dns name start position causing invalid dns error commit 8794496bd6cd3a90082a232a69f961aa94ae87af Author: Nikhil Agrawal <[email protected]> Date: Thu Dec 20 10:50:59 2018 +0530 BUG/MEDIUM: dns: overflowed dns name start position causing invalid dns error In dns_read_name() when dns name is used with compression and start position of name is greater than 255 name read is incorrect and causes invalid dns error. eg: 0xc11b c specifies name compression being used. 11b represent the start position of name but currently we are using only 1b for start position. This should be backported as far as 1.7. (cherry picked from commit 2fa66c3b9348d179e478d3d584471ee8989c3f6e) Signed-off-by: William Lallemand <[email protected]> commit fe7b9f0e397e69e78dfe76ce364f409833bc7d54 Author: Jérôme Magnin <[email protected]> Date: Thu Dec 20 16:47:31 2018 +0100 BUG/MEDIUM: dns: Don't prevent reading the last byte of the payload in dns_validate_response() A regression was introduced with efbbdf72 BUG: dns: Prevent out-of-bounds read in dns_validate_dns_response() as it prevented from taking into account the last byte of the payload. this patch aims at fixing it. this must be backported in 1.8. (cherry picked from commit 8d4e7dc880d2094658fead50dedd9c22c95c556a) Signed-off-by: William Lallemand <[email protected]> commit 929b756c2d67f78a783890ec1ca38a83c7b064d9 Author: Willy Tarreau <[email protected]> Date: Sat Dec 15 16:55:36 2018 +0100 BUG/MINOR: logs: leave startup-logs global and not per-thread Commit f8188c6 ("MEDIUM: threads/logs: Make logs thread-safe") made logs thread-local but it also made the copy of the startup-logs thread-local, meaning that when threads are configured, upon startup the list of startup logs appears to be empty. Let's just remove the THEAD_LOCAL directive there, as the check for the startup period is already present. This fix should be backported to 1.8. (cherry picked from commit a648399c901485a4985f786075535756946113cc) Signed-off-by: William Lallemand <[email protected]> commit 6b6a350afe3b08a1a60c80fe9120a1c9d10448ef Author: Willy Tarreau <[email protected]> Date: Thu Dec 13 00:59:21 2018 +0100 [RELEASE] Released version 1.8.15 Released version 1.8.15 with the following main changes : - MINOR: threads: Make sure threads_sync_pipe is initialized before using it. - DOC: clarify force-private-cache is an option - BUG/MINOR: connection: avoid null pointer dereference in send-proxy-v2 - BUG/MINOR: backend: check that the mux installed properly - BUG/MEDIUM: buffers: Make sure we don't wrap in buffer_insert_line2/replace2. - MEDIUM: ssl: add support for ciphersuites option…
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, again :-)
Next trouble - Segmentation fault.
I'm doing a small load testing using https://github.com/swiftstack/ssbench
I make 100-200 parallel requests 10Mbyte. (Mostly GET)
If there is enough memory to cache requests - everything works fine.
As soon as the memory runs out, after several connections the program closes with an error.
The program SIGSEGV if it is hollowed when the cache is full.
Backtrace
The text was updated successfully, but these errors were encountered: