Seems like it could be this bug:
http://subversion.apache.org/security/CVE-2011-1783-advisory.txt. Does
anyone know if a patch is available?
Hi,
For a couple of months now we have had a few occasions when an httpd
process uses all available memory (74G) and swap and kills the system.
Since then we have set ulimits and so on but we're keen to understand
why this happens.
From the core file we get the trace below:
warning: no loadable sections found in added symbol-file system-supplied
DSO at 0x7fff525ff000
Core was generated by `/app/Subversion/linux/Apache/bin/httpd -k start'.
#0 0x00002b7eb8e15b07 in authz_get_path_access () from
/app/Subversion/linux/lib/libsvn_repos-1.so.0
(gdb) backtrace
#0 0x00002b7eb8e15b07 in authz_get_path_access () from
/app/Subversion/linux/lib/libsvn_repos-1.so.0
#1 0x00002b7eb8e166c6 in svn_repos_authz_check_access () from
/app/Subversion/linux/lib/libsvn_repos-1.so.0
#2 0x00002b7eb964eff3 in subreq_bypass () from
/app/Subversion/linux/Apache/modules/mod_authz_svn.so
#3 0x00002b7eb8ce8f26 in allow_read () from
/app/Subversion/linux/Apache/modules/mod_dav_svn.so
#4 0x00002b7eb8ce915e in authz_read () from
/app/Subversion/linux/Apache/modules/mod_dav_svn.so
#5 0x00002b7eb8e287ec in add_subdir () from
/app/Subversion/linux/lib/libsvn_repos-1.so.0
#6 0x00002b7eb8e29278 in path_driver_cb_func () from
/app/Subversion/linux/lib/libsvn_repos-1.so.0
#7 0x00002b7eb904da9b in svn_delta_path_driver () from
/app/Subversion/linux/lib/libsvn_delta-1.so.0
#8 0x00002b7eb8e2a09d in svn_repos_replay2 () from
/app/Subversion/linux/lib/libsvn_repos-1.so.0
#9 0x00002b7eb8cf4377 in dav_svn__replay_report () from
/app/Subversion/linux/Apache/modules/mod_dav_svn.so
#10 0x00002b7eb8d00d6c in deliver_report () from
/app/Subversion/linux/Apache/modules/mod_dav_svn.so
#11 0x000000000047d721 in dav_method_report (r=<value optimized out>) at
mod_dav.c:4065
#12 dav_handler (r=<value optimized out>) at mod_dav.c:4701
#13 0x000000000043f9ca in ap_run_handler (r=0x241a190) at config.c:157
#14 0x0000000000442c12 in ap_invoke_handler (r=0x241a190) at
config.c:376
#15 0x00000000004734f8 in ap_process_request (r=0x241a190) at
http_request.c:282
#16 0x00000000004707fc in ap_process_http_connection (c=0x24062e0) at
http_core.c:190
#17 0x00000000004468d2 in ap_run_process_connection (c=0x24062e0) at
connection.c:43
#18 0x0000000000495c80 in child_main (child_num_arg=<value optimized
out>) at prefork.c:662
#19 0x0000000000495f24 in make_child (s=0x5e6338, slot=38) at
prefork.c:763
#20 0x0000000000496742 in ap_mpm_run (_pconf=<value optimized out>,
plog=<value optimized out>,
s=<value optimized out>) at prefork.c:898
#21 0x000000000042d498 in main (argc=3, argv=0x7fff52524158) at
main.c:739
The apache config for this repo looks like:
DAV svn
SVNPath /path/to/repo
AuthType Basic
AuthBasicProvider file ldap
AuthzSVNAccessFile /path/to/repo/conf/access-http
SVNPathAuthz short_circuit
Could short-circuit be implicated here?
Strace shows:
brk(0xc7b73000) = 0xc7b73000
brk(0xc7b95000) = 0xc7b95000
brk(0xc7bb7000) = 0xc7bb7000
- Ad infinitum -
There doesn't appear to be anything particularly funky with the
access-http file of the repo we guess is the problem, although we can't
be sure which repo it was. Gdb would not show me the locals, and as the
req is not logged until after completion we can't be sure. We will
enable mod_log_forensic at the w/e.
Any advice much appreciated.
Cheers, jamie
===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
Received on 2011-11-11 13:57:58 CET