Skip to content

Fix memory leak of parameter name after an RFC2231 parameter#61

Open
iliaal wants to merge 1 commit into
php:masterfrom
iliaal:fix/rfc2231-name-leak
Open

Fix memory leak of parameter name after an RFC2231 parameter#61
iliaal wants to merge 1 commit into
php:masterfrom
iliaal:fix/rfc2231-name-leak

Conversation

@iliaal
Copy link
Copy Markdown

@iliaal iliaal commented Jun 7, 2026

currentencoded was set to 1 on the first RFC2231 (name*N) parameter and never reset, so every later parameter took the is_rfc2231_name finalize branch. When a later plain parameter arrived, neither the !currentencoded branch (stale 1) nor the namechanged branch (stale 0) consumed it, so the recombined parameter name was neither stored nor freed. Resetting currentencoded per parameter routes the plain parameter back through the normal path, which stores and frees it.

Reproducer: parsing Content-Type: x/y; a*0="foo"; b="bar" leaks one allocation per plain parameter that follows an encoded one.

currentencoded was set to 1 on the first RFC2231 (name*N) parameter and
never reset, so every later parameter took the is_rfc2231_name finalize
path. When a later plain parameter arrived, neither the !currentencoded
branch (stale 1) nor the namechanged branch (stale 0) consumed its name,
so the emalloc'd name was neither stored nor freed. A header such as
"Content-Type: x/y; a*0=\"foo\"; b=\"bar\"" leaked one allocation per
plain-after-encoded parameter.

Reset currentencoded per parameter so it reflects the current parameter
only; the plain parameter now takes the !currentencoded branch, which
stores and frees its name.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant