httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ralf S. Engelschall)
Subject Re: mod_rewrite/1234: Improper statck variable initialization in mod_rewrite (fwd)
Date Wed, 22 Oct 1997 08:19:52 GMT

In article <> you wrote:

> Anyone?  I stared at this for about an hour, and I couldn't reconstruct in
> my head how this patch would be needed.  In any event the patch isn't
> portable so we can't use it.  But if someone can figure this one out it's
> worth some guru points I'd say.  IRIX boxes use spencer's regex, so if
> this is a bug on IRIX it'll be a bug lots of places.

> I've included a patch from myself down below which removes some manifest
> constants in mod_rewrite.  It shouldn't change behaviour (or fix the bug). 

>>Synopsis:       Improper statck variable initialization in mod_rewrite
>>Release:        1.1 up to 1.2.4
> SGI IRIX 6.2 6.3 6.4

> I believe the problem is platform-independent
>> In file mod_rewrite.c
>> static int apply_rewrite_rule(request_rec *r, rewriterule_entry *p, char
>> *perdir)
>> {
>>     char *uri;
>>     char *output;
>>     int flags;
>>     char newuri[MAX_STRING_LEN];
>>     char port[32];
>>     regex_t *regexp;
>>     regmatch_t regmatch[10];		<====
>> should be changed to:
>>      regmatch_t regmatch[10] = {0,0};
>> Otherwise, you get random garbage off the stack.

I'm the option the requested initialization patch is wrong, too.  Because
{0,0} is totally wrong and I cannot see why we need a initialization at all.
When something dumps core it can be only our pregsub. But this function has
checks for no matching cases.  And the regex-library functions should only use
this array for results. There is no need to read something in from this array.

I also checked our Spencer regex-version (perhaps IRIX uses a similar version)
and found that matcher() (called from within regcomp()) reads from regmatch
only when one uses the STARTEND feature which we don't. So, I'm not sure, but
it seems that the problem lies outside Apache and that there is no really
portable way to make a workaround (as Dean already said).

> We find that the server would segv under some conditions, depending
> on what happened to be on the stack.

Either way: +1 for our cleanup patch, Dean. Its a good and useful one.

                                       Ralf S. Engelschall

View raw message