Brian Pane wrote:
+1 for the patch in 2.0.44.OK, I took another look at the dump. We have 4 saved input buffers. The oldest contains a good request line. The others contain a monster cookie where the original buffer lengths are 1460, 1460, and 5840. So getline gave up when it saw the total length was 8720.
Longer term, a better solution might be able to fix the problem
closer to its source. I'm assuming, based on the code, that the
problem only occurs when the "folding" logic in ap_get_mime_headers_core
is invoked. That's the only case I see where the the size of the
field can grow arbitrarily large.
But what killed us is that ap_escape_html's input and output strings are overlapping, and it is processing its own output as input:
(gdb) fr 0
#0 ap_escape_html (p=0x8152018,
s=0x8158018 "Cookie: ASPSESSIONIDGQGQGTHO=FDLGHGOBJJJNPCKBHGOGAFFP; DTMLASTPOPUP=%7Bts+%272002%2D12%2D02+22%3A39%3A34%27%7D; CFTOKEN=16145632; VJ UTrackID=66.200.155.34.14801038898591969; AFFILIATE_SCOPE=N; ASPSES"...) at util.c:1703
1703 x[j] = s[i];
(gdb) p x
$10 = 0x8158b80 "Cookie: ASPSESSIONIDGQGQGTHO=FDLGHGOBJJJNPCKBHGOGAFFP; DTMLASTPOPUP=%7Bts+%272002%2D12%2D02+22%3A39%3A34%27%7D; CFTOKEN=16145632; VJ UTrackID=66.200.155.34.14801038898591969; AFFILIATE_SCOPE=N; ASPSES"...
Notice that the hex addresses of the two variables are only 0xb68 == 2920 bytes apart. That makes some sense; 2920 = 1460+1460. vi'ing the dump, I can see that ap_escape_html tried to escape its own output repeatedly until it seg faulted. The string below appears many times with another "amp;" added each iteration as it re-escapes the ampersand:
MC1=V=2&GUID=3
89F8C3Cookie: ASPSESSIONIDG
We know that ap_get_mime_headers thought there was a problem with the length of the cookie due to where it called ap_escape_html, even though the length returned by getline was only 2920 bytes. s wasn't null terminated, but my patch won't insert a null in an appropriate place as it stands now. I'll go rework it.
Greg
