https://bz.apache.org/bugzilla/show_bug.cgi?id=68527
--- Comment #1 from SamCo DWS <[email protected]> --- I can independently confirm this crash on a completely different setup, which shows the bug is not specific to a particular rewrite/config style but a general collision between mod_rewrite (per-directory context) and mod_dir's fixup handler whenever a directory request gets rewritten to a handler-bound target. Environment: - Debian 13 (Trixie), Apache/2.4.67 - PHP-FPM 8.4, connected via mod_proxy_fcgi (SetHandler "proxy:unix:/run/php/php8.4-fpm.sock|fcgi://localhost/") - Trigger: per-directory .htaccess (AllowOverride), NOT a vhost-level RewriteRule as in the original report: RewriteEngine On RewriteRule ^$ index.php?_route[controller]=index [L,QSA] - Request: GET / (i.e. the exact directory root, matching ^$) Backtrace (with debug symbols via debuginfod, Apache 2.4.67): #0 __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 #1 fixup_dir (r=...) at ./modules/mappers/mod_dir.c:280 #2 dir_fixups (r=...) at ./modules/mappers/mod_dir.c:395 #3 ap_run_fixups (r=...) at ./server/request.c:86 #4 ap_process_request_internal (r=...) at ./server/request.c:416 #5 ap_process_async_request (r=...) at ./modules/http/http_request.c:450 ... Identical root cause as already identified in this report: both unguarded strcmp(r->content_type, DIR_MAGIC_TYPE) calls in fixup_dir() (the DirectoryCheckHandler==On branch AND the REWRITE_REDIRECT_HANDLER_NAME "step aside" branch) dereference r->content_type without a NULL check. In our case r->content_type was NULL because the type_checker phase runs before the per-directory mod_rewrite fixup sets the proxy handler, so mod_mime never assigns a content type for the directory request before mod_dir's fixup runs. We reproduced this consistently with BOTH DirectoryCheckHandler On and Off - each setting simply routes through a different one of the two unguarded strcmp() calls, so toggling the directive is not a usable workaround. Workaround that does prevent the crash (confirms the NULL r->content_type theory): forcing a non-NULL content type before the fixup phase runs, e.g. <Directory /path/to/app> ForceType text/html </Directory> Given: 1. This has now been independently reproduced on two different Apache versions, two different OS/package bases, two different PHP-FPM versions, and two different rewrite trigger styles (vhost-level vs. .htaccess) - it is clearly a general, easily-triggered defect, not a one-off config quirk. 2. The trigger config (mod_rewrite + mod_proxy_fcgi + PHP-FPM, rewriting a directory root to an index script) is an extremely common real-world pattern for PHP front-controller frameworks. 3. Any unauthenticated client request matching the vulnerable pattern crashes the worker process handling it - this is a trivially triggerable remote DoS vector, not just a functional bug. Given the report has been sitting at NEW since 2024 with a clearly identified root cause and a proposed two-line fix, could this please be reprioritized? The fix suggested in this report (adding `r->content_type &&` before both strcmp() calls in fixup_dir()) is minimal and low-risk. Happy to provide our full core dump / additional backtraces if useful. -- 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]
