BUG/MEDIUM: htx: smp_prefetch_htx() must always validate the direction
It is possible to process a channel based on desynchronized info if a
request fetch is called from a response and conversely. However, the
code in smp_prefetch_htx() already makes sure the analysis has already
started before trying to fetch from a buffer, so the problem effectively
lies in response rules making use of request expressions only.
Usually it's not a problem as extracted data are checked against the
current HTTP state, except when it comes to the start line, which is
usually accessed directly from sample fetch functions such as status,
path, url, url32, query and so on. In this case, trying to access the
request buffer from the response path will lead to unpredictable
results. When building with DEBUG_STRICT, a process violating these
rules will simply die after emitting:
FATAL: bug condition "htx->first == -1" matched at src/http_htx.c:67
But when this is not enabled, it may or may not crash depending on what
the pending request buffer data look like when trying to spot a start
line there. This is typically what happens in issue #806.
This patch adds a test in smp_prefetch_htx() so that it does not try
to parse an HTX buffer in a channel belonging to the wrong direction.
There's one special case on the "method" sample fetch since it can
retrieve info even without a buffer, from the other direction, as
long as the method is one of the well known ones. Three, we call
smp_prefetch_htx() only if needed.
This was reported in 2.0 and must be backported there (oldest stable
version with HTX).
(cherry picked from commit a6d9879e69d65e8821347860394829c4dc72f937)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 05f3910f58a8d5e0710a4a8eea82f8bc24861e32)
[wt: adjusted context; chn already checked; 3 args to smp_prefetch_htx()]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 6a7b5ba87b536c510b0ce849f26caf6f1b4d54bf)
[wt: ctx adj for legacy coexistence]
Signed-off-by: Willy Tarreau <w@1wt.eu>
1 file changed