mirror of
https://github.com/haproxy/haproxy.git
synced 2026-02-20 00:10:41 -05:00
d8ee85a0a3
Despite much care around handling the content-length as a 64-bit integer, forwarding was broken on 32-bit platforms due to the 32-bit nature of the ->to_forward member of the "buffer" struct. The issue is that this member is declared as a long, so while it works OK on 64-bit platforms, 32-bit truncate the content-length to the lower 32-bits. One solution could consist in turning to_forward to a long long, but it is used a lot in the critical path, so it's not acceptable to perform all buffer size computations on 64-bit there. The fix consists in changing the to_forward member to a strict 32-bit integer and ensure in buffer_forward() that only the amount of bytes that can fit into it is considered. Callers of buffer_forward() are responsible for checking that their data were taken into account. We arbitrarily ensure we never consider more than 2G at once. That's the way it was intended to work on 32-bit platforms except that it did not. This issue was tracked down hard at Exosec with Bertrand Jacquin, Thierry Fournier and Julien Thomas. It remained undetected for a long time because files larger than 4G are almost always transferred in chunked-encoded format, and most platforms dealing with huge contents these days run on 64-bit. The bug affects all 1.5 and 1.4 versions, and must be backported. |
||
|---|---|---|
| .. | ||
| acl.h | ||
| auth.h | ||
| backend.h | ||
| buffers.h | ||
| capture.h | ||
| checks.h | ||
| counters.h | ||
| fd.h | ||
| freq_ctr.h | ||
| global.h | ||
| hdr_idx.h | ||
| httperr.h | ||
| lb_chash.h | ||
| lb_fwlc.h | ||
| lb_fwrr.h | ||
| lb_map.h | ||
| log.h | ||
| pattern.h | ||
| peers.h | ||
| pipe.h | ||
| port_range.h | ||
| proto_http.h | ||
| proto_tcp.h | ||
| protocols.h | ||
| proxy.h | ||
| queue.h | ||
| server.h | ||
| session.h | ||
| signal.h | ||
| stick_table.h | ||
| stream_interface.h | ||
| task.h | ||
| template.h | ||