include/types/global.h | 3 2 + 1 - 0 !
src/acl.c | 3 1 + 2 - 0 !
src/cfgparse.c | 12 7 + 5 - 0 !
src/checks.c | 10 5 + 5 - 0 !
src/dumpstats.c | 16 8 + 8 - 0 !
src/haproxy.c | 13 7 + 6 - 0 !
src/proto_http.c | 12 6 + 6 - 0 !
tests/0000-debug-stats.diff | 8 4 + 4 - 0 !
8 files changed, 40 insertions(+), 37 deletions(-)

 bug/major: trash must always be the size of a buffer
X-Git-Tag: v1.4.21~7

src/proto_http.c | 22 22 + 0 - 0 !
1 file changed, 22 insertions(+)

 bug/critical: using http information in tcp-request content may crash the process
X-Git-Tag: v1.4.23~1

src/proto_http.c | 6 4 + 2 - 0 !
1 file changed, 4 insertions(+), 2 deletions(-)

 bug/critical: fix a possible crash when using negative header
 occurrences

When a config makes use of hdr_ip(x-forwarded-for,-1) or any such thing
involving a negative occurrence count, the header is still parsed in the
order it appears, and an array of up to MAX_HDR_HISTORY entries is created.
When more entries are used, the entries simply wrap and continue this way.

A problem happens when the incoming header field count exactly divides
MAX_HDR_HISTORY, because the computation removes the number of requested
occurrences from the count, but does not care about the risk of wrapping
with a negative number. Thus we can dereference the array with a negative
number and randomly crash the process.

This bug has been present since the introduction of the negative offset
count in 1.4.4 via commit bce70882. It has been reported by David Torgerson
who offered some debugging traces showing where the crash happened, thus
making it significantly easier to find the bug!

This fix must absolutely be backported to 1.4.