The following reply was made to PR mod_cern_meta/1500; it has been noted by
GNATS.
From: "Joe Condon"<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], "Roy Wood"<[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: mod_cern_meta/1500: mod_cern_meta corrupts memory pool
Date: Mon, 8 Dec 1997 12:20:33 -0500
--0__=jHvwgRyGvCtXxWMwaLuVLoaIdwXBMTb1Ah3PTjwwo0vTfqlY4IlKTzDQ
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
Dean,
To provide a little more background, let me describe the problem we wer=
e
experiencing. The access log would sometimes contain garbage (portions =
of
HTTP documents) in the Remote User ID field. This corruption only appea=
red
when with the Stronhold version of Apache. I put together a set of
debug/trace routines that logged to a file when documents were served. =
With
these routines I was able to trace down where I think the problem is.
Because the problem manifests itself as a corrupt User ID, I began addi=
ng
trace statements throughout the server code in order to determine when =
the
User ID field became corrupt. This corruption occurred towards the end =
of
the transaction when a buffer was allocated from the memory pool and a
document was read into it from the SSL module. I have to apologize if m=
y
descriptions are not quite exact, I trouble shot this a couple of weeks=
ago
and my memory is not 100% and I don?t have the time to refresh it right=
now. Anyway, from the above observation, either the allocation of the
buffer overlapped the previous allocation for the User ID or the read i=
nto
the buffer exceeded the size of the buffer allocation or the area
previously allocated for the User ID had been freed and the buffer was
allocated in the area of the freed User ID allocation. The later is the=
case, with my trace routines, I listed the address of the User ID
allocation at the time it was made. I then traced ALL de-allocations an=
d
found that the pool containing the User ID allocation was being freed =
in
the cern_data module. Once free, that location in memory could be re-us=
ed
by a future allocation which is what happens with the Stronghold versio=
n.
Any frees of the memory containing the Remote User ID must NOT occur pr=
ior
to the writing of the access log since one of the fields in the log is =
the
Remote User ID. This problem did not show up before we started using
Stronghold probably because the memory containg the value of the Remote=
User ID was not getting overwritten at a later time by the vanilla Apac=
he
server. If the memory containing the Remote User ID gets freed prematur=
ely,
it?s value will get written out to the access log correctly unless
something else overwrites that area of memory.
We have contacted Stronghold about this but they have not gotten back t=
o us
with any comments. As far as reproducing this problem without the
Stronghold modules, you could temporarily modify the allocation and
de-allocation routines in Apache to do a memset() of the area being
allocated or de-allocated. Set the area to all ?X?s. This should NOT ca=
use
any side effects other than a slight performance hit. After doing this,=
You
will probably notice some corruption in the access log, specifically, t=
he
Remote User ID field should now contain ?X?s. Of course, you must compi=
le
Apache with the Cern Meta Module to observe this problem. If you have a=
ny
additional questions please contact me.
Regards,
J. Condon
---------------------- Forwarded by Joe Condon/GCS/US/Unisys on 12/08/9=
7
11:37 AM ---------------------------
=20
(Embedded =20
image moved [EMAIL PROTECTED] =20
to file: 12/06/97 06:07 PM =20
PIC31930.PCX) =20
=20
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
cc: (bcc: Roy Wood/GCS/US/Unisys)
Subject: Re: mod_cern_meta/1500: mod_cern_meta corrupts memory pool
=
--0__=jHvwgRyGvCtXxWMwaLuVLoaIdwXBMTb1Ah3PTjwwo0vTfqlY4IlKTzDQ
Content-type: text/plain; charset=us-ascii
[In order for any reply to be added to the PR database, ]
[you need to include <[EMAIL PROTECTED]> in the Cc line ]
[and leave the subject line UNCHANGED. This is not done]
[automatically because of the potential for mail loops. ]
Synopsis: mod_cern_meta corrupts memory pool
State-Changed-From-To: open-analyzed
State-Changed-By: dgaudet
State-Changed-When: Sat Dec 6 16:07:23 PST 1997
State-Changed-Why:
I don't think that destroy_sub_req() is at fault. It clears
a sub pool of the main request, not the pool of the main
request. Something else must be at issue. Can you demonstrate
this bug with plain apache? Have you reported it to the stronghold
folks?
Dean
--0__=jHvwgRyGvCtXxWMwaLuVLoaIdwXBMTb1Ah3PTjwwo0vTfqlY4IlKTzDQ
Content-type: application/octet-stream;
name="PIC31930.PCX"
Content-transfer-encoding: base64
CgUBCAAAAABoACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABaQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAD1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPH
E8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sT
zRPHE8MTwhPwEwzIBgzYE8wTxhPDE8IT7hPOBtcTzBPGE8MTE+wTwgbCBwbCEgbCEgbCEsUG1hPL
E8YTwxMT6hMMwgYHwgLCAwISwgfEEsMCwwbVE8sTxRPDExPpE8MGAwcCBwMCwhLDB8ISwgISwgLD
BtUTyhPFE8MTE+gTwgIHA8ICEw4DDgLDE8USwwLCEMIG1BPKE8UTwxMT5xMCAwcDAg4TDgITwgIS
D8ISD8ISBRICEcICwwbUE8oTxRPCExPmEwYCBwMCDgIOwgLDExITEhPCEg8GxgLDBtMMDAfJE8QT
whMT5hMGwwITBgMCDhLFEw8SE8ISBgIDwhIDEsMGB9MDxwwHxRPDExPlEwYHAhESAg8CwhMPwhMP
xBMPxRIQwgIDAgMCBtMDxwPEDAfDE8IT4RMHwwzCBgLCEhMCDxLIE8MSD8MSwwIQAwIDBgfSDMkD
wgPCDAfCExPbEwfGDMIDDAIHERITEhMSwxMPwxMPwxPDEgIDAgMCwwMCBgzREwfHDMYDDMITE9YT
B8UMyAMGB8ICBhLDAsYTEhMSExIPwhIHAgcCAwUQAgYRBgfSE8UTB8QMwgMMwhMT0hMHxAzLA8IM
BsISDxESExITAw4DxBMSExITwxICBwPCAsMDDMIGB9ITyRMHwwzCExPPEwfDDMkDxQwHwhMGBxIT
AhECEwMOAg7DExITDxMPwxIDAgMCBwMCDAYRBgfSE8kTwhPCDMITE8wTB8MMxwPEDMIHxxMGxBLD
Ag4DDgIGwg/IEgIDwgIDAgwCEMIGB9ITyRMHDAcMwhMTyhMHwgzGA8MMwgfMEwYHwhLCEAIOAg4C
DhDDAhIPxhIFAgXDAgUCEQYH0hPHEwfCDAcPDMITE8gTB8IMxQPDDAfQEwbDEhDEAhAOEA4QwgLG
EgcSBhIGBcMCBcIGB9ATB8UMEwfCDA8HDwwHwhMTxhMHwgzEA8MMB9MTBgfCEhADEMICDhAOEMIC
EQIDxxIGBwbCAgUCEQYHyxMHxAwHwhMHEwzCEwcPBw8MB8MTE8UTBwzEA8IMB9YTBsQSEAMCA8UC
EQIDAgPDEgcSBgfCBgUQAhDCBgfGEwfEDAfGE8INEwzCEw8HwgwHwxPCE8QTBwzDA8IMB9gTBgfE
EhACEMYCEQIDAsQSBhLDBsICEALCBgfCEwfDDAfKEwfCDRMHwhPCDAfEE8ITE8MTBwzCA8IMB9oT
DBIHwxLDDBEDxQIDAgPDEgYSBgfCBgIQAhAGDAfCEwzDE8MHyRMHwhPCBxMHxRPDExPDEwzCAwwH
3RMGxxICEQPDAgMCA8MSBhIGBwYMBhACEAIGDMMTDBPCB8YTwwfHEwfGE8MTwhPDEwwDDAfeEwYH
xxICEQPDAgMCwhIGEgYHBgwGEAIQAsIGB8MTDMYTwwfKEwzGE8MTwhPDE8IMB98TDBLCB8USAgMR
xAISB8ISBgcGDAYQBhAGEAYMB8MMB8kTwwfHEwzGE8MTwhPDEwwPwgzfEwYSB8ISB8ISAhECAwID
EgcSBwYHBgwGEAYQxgzDD8IHxRPDB8kTBwzGE8MTwhPDEwzDD8QM3BPCBhIGwxIGAhECAwIHBgcG
yAzJDxMHzRMHwwwHxxPDE8ITwxMHDMYPxwwH1BMGEgYSBhLLDM4PwwwTDMcTwgfEDAfJE8QTwhMT
xBMHwgzLD9sM0w/GDAfDEwzDEwfEDAfLE8YTwxMTxhMHxAztD8gMBgfIE8QMB84TxxPDE8ITyhMH
xwzbD8sMEAUMBcIMwgYH1RPKE8UTwxMT0RMH2wwGEAYQBhACBQwFDAUMBgwHBgfWE8sTxRPDExPu
EwYMBhAGEAIGDAYMwwYH1xPLE8YTwxMT8BPKBgfYE8wTxhPDExP1E9sTzRPHE8MTwhP1E9sTzRPH
E8MTwhMMAAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD/
/wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8A
AAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A
//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAA
AP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA
/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCk
gICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vw
oKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw
//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzA
psrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDA
wNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICA
wMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACA
AICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACA
gACA//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////
--0__=jHvwgRyGvCtXxWMwaLuVLoaIdwXBMTb1Ah3PTjwwo0vTfqlY4IlKTzDQ--
