https://bz.apache.org/bugzilla/show_bug.cgi?id=63516

--- Comment #2 from Sam Vaughan <[email protected]> ---
Hi Christophe,

It's true that you need to install mod_perl to see this bug, but it's hard to
blame mod_perl for this issue.  It's using the memory pool provided to it to
add a define to the server configuration, and the line of code that does this
has been there unchanged for at least 15 years.  Perhaps you could ban modules
from appending to the ap_server_config_defines global array, but then you'd be
breaking mod_perl installations that rely on being able to use the MODPERL2
configuration option.

I've only been looking at the source for a day or two, but my first impression
is that Apache needs to defend itself against the exposure it created by making
ap_server_config_defines a global array.

I see other bugs out there that have raised similar issues with freed memory
addresses being left in ap_server_config_defines, e.g:

https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1504354

The fix for that was r1643825:

http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?r1=1642847&r2=1643825&pathrev=1643825&diff_format=h

Looking at the diff I see that there's already a reset_config_defines()
function.  This suggests that issues with the global ap_server_config_defines
array are not new, and perhaps some of the existing fixes could be leveraged to
deal with this issue as well?

Looking at the Apache SVN repository, I also notice that the calls to
ap_exists_config_define("DUMP_INCLUDES") were added in r1747808 back in 2016. 
This is where the crash occurs, so perhaps it wasn't happening prior to that. 
I haven't been through the code carefully enough to be able to say for sure
whether the ap_server_config_defines global is accessed elsewhere or not.

I'm really hoping that this information can help someone come up with a patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to