tree 39f0c3ff2183f54349d03006dae384abd2b2bd63
parent c8d167bcfb4ae6ae19368a66d5be3e92613e0df0
author Willy Tarreau <w@1wt.eu> 1592317979 +0200
committer Willy Tarreau <w@1wt.eu> 1592320022 +0200
encoding latin1

BUG/MEDIUM: cfgparse: use parse_line() to expand/unquote/unescape config lines

Issue 22689 in oss-fuzz shows that specially crafted config files can take
a long time to process. This happens when variable expansion, backslash
escaping or unquoting causes calls to memmove() and possibly to realloc()
resulting in O(N^2) complexity with N following the line size.

By using parse_line() we now have a safe parser that remains in O(N)
regardless of the type of operation. Error reporting changed a little bit
since the errors are not reported anymore from the deepest parsing level.
As such we now report the beginning of the error. One benefit is that for
many invalid character sequences, the original line is shown and the first
bad char or sequence is designated with a caret ('^'), which tends to be
visually easier to spot, for example:

  [ALERT] 167/170507 (14633) : parsing [mini5.cfg:19]: unmatched brace in environment variable name below:
    "${VAR"}
      ^
or:

  [ALERT] 167/170645 (14640) : parsing [mini5.cfg:18]: unmatched quote below:
    timeout client 10s'
                      ^

In case the target buffer is too short for the new line, the output buffer
is grown in 1kB chunks and kept till the end, so that it should not happen
too often.

Before this patch a test like below involving a 4 MB long line would take
138s to process, 98% of which were spent in __memmove_avx_unaligned_erms(),
and now it takes only 65 milliseconds:

  $ perl -e 'print "\"\$A\""x1000000,"\n"' | ./haproxy -c -f /dev/stdin 2>/dev/null

This may be backported to stable versions after a long period of
observation to be sure nothing broke. It relies on patch "MINOR: tools:
add a new configurable line parse, parse_line()".