tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <>
Subject RE: [PATCH] Potential buffer overflow attach in mod_jk
Date Thu, 27 Sep 2001 09:40:10 GMT

I'll back port to J-T-C....

Henri Gomez                 ___[_]____
EMAIL :        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

>-----Original Message-----
>From: Bill Barker []
>Sent: Thursday, September 27, 2001 2:42 AM
>Subject: Re: [PATCH] Potential buffer overflow attach in mod_jk
>Here's with jk_pool_strdup (against RC1, not HEAD).  It looked 
>to me like
>uw_map->p wasn't suitable for per-request allocations (i.e. it 
>would just
>eat memory until the server was re-started), and since this is 
>in common, I
>couldn't use ap_strdup since that breaks all non-Apache servers.
>----- Original Message -----
>From: "Keith Wannamaker" <>
>To: <>
>Sent: Wednesday, September 26, 2001 5:25 PM
>Subject: RE: [PATCH] Potential buffer overflow attach in mod_jk
>> Hi Bill, would you resubmit a patch that makes use of either
>> Apache or jk's pools?  ie ap_strdup or jk_pool_strdup.
>> That would be a better way to solve the problem.  Apache
>> modules should and do avoid os memory-allocation routines
>> like the plague.  I think uw_map->p would be ok, but please
>> do some testing.
>> Thanks,
>> Keith
>> | -----Original Message-----
>> | From: Bill Barker []
>> | Sent: Wednesday, September 26, 2001 2:37 PM
>> | To:
>> | Subject: Fw: [PATCH] Potential buffer overflow attach in mod_jk
>> |
>> |
>> | Urm, let's try that again with a patch that at least compiles......
>This message is intended only for the use of the person(s) 
>listed above 
>as the intended recipient(s), and may contain information that is 
>PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
>you may not read, copy, or distribute this message or any attachment.  
>If you received this communication in error, please notify us 
>by e-mail and then delete all copies of this message and any 
>In addition you should be aware that ordinary (unencrypted) 
>e-mail sent 
>through the Internet is not secure. Do not send confidential 
>or sensitive 
>information, such as social security numbers, account numbers, 
>identification numbers and passwords, to us via ordinary (unencrypted) 

View raw message