fix: free two memory leaks found by the valgrind soak - #94
Open
fzipi wants to merge 3 commits into
Open
Conversation
- Move msc_process_request_body() into the handler phase (hook_request_late) instead of calling it per input-filter bucket - Register hook_request_late via ap_hook_handler (not fixups) and read the body with ap_setup_client_block()/ap_get_client_block() so the input filter runs; create the transaction context in hook_insert_filter if missing - Set r->status in addition to r->status_line so interventions return the configured HTTP status - Fix input_filter() calling ap_remove_output_filter() instead of ap_remove_input_filter() - Check apr_bucket_read() return value in output_filter() Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
msc_create_rules_set() heap-allocates a RulesSet outside of any APR pool, and nothing ever freed it. Every graceful restart re-parses the config and creates a new one without releasing the old, leaking one RulesSet per restart -- this is issue owasp-modsecurity#82. Register an apr_pool_cleanup that calls msc_rules_cleanup() (the public API's documented counterpart to msc_create_rules_set(), also used by the nginx connector for this exact purpose) when the config pool is destroyed, tying the RulesSet's lifetime to the config generation it belongs to. Confirmed with tools/soak.sh: a memcheck soak with periodic graceful restarts previously reported a "definitely lost" block in msc_create_rules_set (rules_set.cc:278) per restart; after this fix it reports none. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
msc_intervention() heap-allocates intervention.url and intervention.log for the caller to free (see libmodsecurity's intervention::free() in intervention.h), but process_intervention() never did, leaking one allocation per blocked request -- unbounded growth under sustained attack traffic. Switch the Location header from apr_table_setn() to apr_table_set() so the copy stored in r->headers_out survives freeing the original, then free both strings before returning. Also drops the dead "(no log message was specified)" fallback, which was never read and would otherwise get passed to free() as a string literal. Confirmed with tools/soak.sh: a memcheck soak previously reported hundreds of KB "definitely lost" per run in modsecurity::Transaction::intervention (transaction.cc:1382) via strdup; after this fix it reports none. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
fzipi
changed the title
fzipi
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacks on #91 (request body processing fixes) -- this branch is based on
fix/request-body-processing, so the diff here is just the two commits below until #91 merges.Follow-up to #93, which added
tools/soak.sh(a valgrind memcheck/helgrind soak of the running module) and used it to find these two leaks. This PR fixes both.Summary
msc_config.c: free theRulesSeton config-pool cleanup.msc_create_rules_set()heap-allocates aRulesSetoutside of any APR pool, and nothing ever freed it. Every graceful restart re-parses the config and creates a new one without releasing the old -- this is issue apache graceful restart + Apache connector + rules = memory leak #82. Fixed by registering anapr_pool_cleanupthat callsmsc_rules_cleanup()(the public API's documented counterpart, and the same pattern the nginx connector already uses) when the config pool is destroyed.mod_security3.c: free the intervention log/url strings after use.msc_intervention()heap-allocatesintervention.urlandintervention.logfor the caller to free (per libmodsecurity's ownintervention::free()inintervention.h), butprocess_intervention()never did -- one leaked allocation per blocked request, growing unbounded under sustained attack traffic. Fixed by switching theLocationheader fromapr_table_setn()toapr_table_set()(so the copy survives freeing the original) and freeing both strings before returning.Test plan
makecompiles clean, no new warnings./test-connector.shstill passes all 6 checksUSE_VALGRIND=1 tools/soak.sh(30s, 2 concurrent, restarts every 10s) reported a "definitely lost" block inmsc_create_rules_setper graceful restart, plus hundreds of KB "definitely lost" inmodsecurity::Transaction::interventionviastrdup✓ soak clean: 30s @ 2 concurrent, 3 graceful restart(s), no leak/race/crash, WAF verdicts held