www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Condon" <joecon...@unn.unisys.com>
Subject Re: mod_cern_meta/1500: mod_cern_meta corrupts memory pool
Date Mon, 08 Dec 1997 17:30:00 GMT
The following reply was made to PR mod_cern_meta/1500; it has been noted by GNATS.

From: "Joe Condon"<joecondon@unn.unisys.com>
To: dgaudet@apache.org, "Roy Wood"<roywood@unn.unisys.com>
Cc: apbugs@apache.org
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   dgaudet@hyperreal.org                             =20
  to file:      12/06/97 06:07 PM                                 =20
  PIC31930.PCX)                                                   =20
                                                                  =20
 
 
 
 To:   apache-bugdb@apache.org, dgaudet@apache.org, roy.wood@unisys.com
 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 <apbugs@Apache.Org> 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--
 

Mime
View raw message