httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian J. France" <>
Subject mod_dbd crash
Date Fri, 17 Mar 2006 16:03:44 GMT
In a virtual host block if you forget to add DBDriver or DBDParams in  
the main section, but add a AuthBasicProvider dbd and  
AuthDBDUserPWQuery in a <Location> block it will core dump while  
processing AuthDBDUserPWQuery (see below).

This is with 2.2.0 and trunk (core dump from trunk).  The problem is  
when ap_dbd_prepare is called to process AuthDBDUserPWQuery, the svr  
config pointer will be NULL and not checked before being used.

A quick fix is to have ap_dbd_prepare print a warning and abort, but  
I think a better fix it to have ap_dbd_prepare return a status value  
(or maybe a string pointer or something) that mod_authn_dbd and other  
modules could check and raise an error.

Here is a patch to mod_dbd.c and mod_authn_dbd.c (not sure if  
anything else uses that function) that returns a status code:


142 DBD_DECLARE_NONSTD(void) ap_dbd_prepare(server_rec *s, const char  
143                                         const char *label)
144 {
145     svr_cfg *svr = ap_get_module_config(s->module_config,  
146     dbd_prepared *prepared = apr_pcalloc(s->process->pool, sizeof 
147     prepared->label = label;
148     prepared->query = query;
149     prepared->next = svr->prepared;
150     svr->prepared = prepared;
151 }

sudo gdb ./httpd
(gdb) run -t
Program received signal SIGSEGV, Segmentation fault.
ap_dbd_prepare (s=0x57c2a8, query=0x659f80 "<query>", label=0x65a038  
"authn_dbd_6") at mod_dbd.c:149
149         prepared->next = svr->prepared;
(gdb) bt
#0  ap_dbd_prepare (s=0x57c2a8, query=0x659f80 "<query>",  
label=0x65a038 "authn_dbd_6") at mod_dbd.c:149
#1  0x0000000801832f7e in authn_dbd_prepare (cmd=0x7fffffffe990,  
     query=0x659f80 "<query>") at mod_authn_dbd.c:73
#2  0x0000000000433b03 in invoke_cmd (cmd=0x801933800,  
parms=0x7fffffffe990, mconfig=0x659f48, args=0x603325 "") at config.c: 
#3  0x000000000043448b in ap_walk_config (current=0x603230,  
parms=0x7fffffffe990, section_vector=0x659758) at config.c:1141
#4  0x000000000042b06c in urlsection (cmd=0x7fffffffe990,  
mconfig=0x57c290, arg=0x659c33 "") at core.c:1942
#5  0x0000000000433b03 in invoke_cmd (cmd=0x44ffe8,  
parms=0x7fffffffe990, mconfig=0x657c28, args=0x603078 "\"/\">") at  
#6  0x000000000043448b in ap_walk_config (current=0x603038,  
parms=0x7fffffffe990, section_vector=0x657650) at config.c:1141
#7  0x000000000042b7e0 in virtualhost_section (cmd=0x7fffffffe990,  
dummy=0x57c290, arg=0x657028 "\"<host>m:443\"") at core.c:2206
#8  0x0000000000433b03 in invoke_cmd (cmd=0x450010,  
parms=0x7fffffffe990, mconfig=0x5b2570, args=0x6025f8 "\"<host>:443 
\">") at config.c:768
#9  0x000000000043448b in ap_walk_config (current=0x6025b8,  
parms=0x7fffffffe990, section_vector=0x5b2150) at config.c:1141
#10 0x00000000004352e2 in ap_process_config_tree (s=0x57c2a8,  
conftree=0x65a038, p=0x57d028, ptemp=0x0) at config.c:1743
#11 0x000000000042064d in main (argc=2, argv=0x7fffffffeb28) at  
(gdb) p svr
$1 = (svr_cfg *) 0x0

View raw message