Bug 57531 - 2.4.12 segmentation fault when accessing host on Listen port that doesn't have defined virtual host block
Summary: 2.4.12 segmentation fault when accessing host on Listen port that doesn't hav...
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: All (show other bugs)
Version: 2.4.10
Hardware: PC Linux
: P2 normal with 2 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: FixedInTrunk
Depends on:
Reported: 2015-02-03 21:17 UTC by Kurt Newman
Modified: 2015-06-02 22:08 UTC (History)
1 user (show)

GDB stack trace (2.36 KB, text/plain)
2015-02-03 21:17 UTC, Kurt Newman
httpd.conf (672 bytes, text/plain)
2015-02-03 21:18 UTC, Kurt Newman
errordocument.conf (1.63 KB, text/plain)
2015-02-03 21:18 UTC, Kurt Newman

Note You need to log in before you can comment on or make changes to this bug.
Description Kurt Newman 2015-02-03 21:17:58 UTC
Created attachment 32428 [details]
GDB stack trace

Basic setup instructions:

Set up shtml ErrorDocument definitions (and corresponding Handler), setup Listen directive for multiple ports, and create a virtual host block.


2.4.10 would handle this correctly, but now causes children (when in prefork mode) for 2.4.12 to segfaults.

Testing setup:
2.4.10 without patches
2.4.12 without patches

I've attached two basic configuration files that duplicate this succinctly, as well as a stack trace.
Comment 1 Kurt Newman 2015-02-03 21:18:17 UTC
Created attachment 32429 [details]
Comment 2 Kurt Newman 2015-02-03 21:18:32 UTC
Created attachment 32430 [details]
Comment 3 Brian Behlendorf 2015-03-04 19:00:40 UTC
I am hitting this too, oddly also with the same specific error, 400 Bad Gateway, with the default config file thus pulling in HTTP_BAD_GATEWAY.html.var.  I wonder if it's related to this snippet from:


"Multi-language error documents from 2.2.x may not work unless they are
adjusted to the new syntax of mod_include's #if expr= element or the
directive SSILegacyExprParser is enabled for the directory containing the
error documents."

Is your "400.html" the same file as the stock HTTP_BAD_GATEWAY.html.var?

I tried to see if there was any particular error in HTTP_BAD_GATEWAY.html.var relating to the #if expr= syntax and didn't find anything obvious.  Nor could I reproduce the error with my hand-cobbled HTTP requests designed to trigger 400 responses, but I do get them in production, so realistic traffic can trigger it.  However, when I change my config to eliminate ONLY the following line from my extra/httpd-multilang-errordoc.conf:

#ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var

that stopped all my core dumps, so it strongly suggests either a bug in that error message's server-parsed HTML (which still shouldn't trigger a core dump!!) or an error while processing a bad HTTP request that makes setting up the CGI environment variables fail spectacularly.

Hoping this can get some attention from folks who'd know...
Comment 4 Brian Behlendorf 2015-03-04 22:00:40 UTC
More details:

A friend (jl) noted:
> A quick glance at the code suggested that the request method is
> not set up in the request object and in the function mentioned in the
> stacktrace this leads to strcmp(NULL, "INCLUDED") -> segfault.

So I went about looking for odd-looking requests that might have no method set, and found (IP address anonymized):

x.x.x.x - - [04/Mar/2015:13:36:01 -0800] "\x16\x03\x03" 400 326 "-" "-"

Posts online suggested this was an SSL client attempting to talk SSL to port 80.  And in fact, I could reproduce this by trying to go to


to the point where I could even generate a core, which I couldn't do before.

Anyways, looks like before that strcmp is called the request method should be tested for, or set.

Comment 5 Kurt Newman 2015-03-04 22:09:07 UTC
The way that I was able to re-produce this, was by Listening on 2 ports (80 and 443), accessing port 443, but for a virtual host that isn't defined on that port.
Comment 6 Eric Covener 2015-03-04 22:55:54 UTC
Sorry, this is a recent regression that will be fixed shortly in trunk
Comment 7 Jan Ludewig 2015-03-05 01:08:41 UTC
(In reply to Eric Covener from comment #6)
> Sorry, this is a recent regression that will be fixed shortly in trunk

Looks like you already found the problem?

still, minor correction: the "request method" I mentioned to brian (see comment #4) was actually "r->protocol in ap_add_cgi_vars, in server/util_script.c. My bad, I had written from memory, not checked the actual source again.

Also, I'm looking at revision 1661207, not the released version.
Comment 8 Eric Covener 2015-03-05 02:36:39 UTC
fixed in trunk and proposed for backport, sorry for the delay.  

Comment 9 Kurt Newman 2015-03-05 18:16:29 UTC
Awesome.  Thank you Eric!
Comment 10 Yann Ylavic 2015-06-02 22:06:59 UTC
Backported to 2.4.13 in r1668879.
Comment 11 Yann Ylavic 2015-06-02 22:08:08 UTC
And to 2.2.30 in r1680927.