[php-src] Issue #24114: [FPM] Bound cumulative FCGI_PARAMS allocation per request

Issue: https://github.com/php/php-src/issues/24114 Author: bupt-Yy-young ### Description In the php-src master snapshot 63b0af4a5c400d93510dca7aa998769609fdc26c (2026-10-04), the FastCGI request reader appears to have no cumulative limit for FCGI_PARAMS data. fcgi_read_request() accepts successive non-empty FCGI_PARAMS records until the terminating empty record (main/fastcgi.c:1110-1132). Each record is bounded by FCGI_MAX_LENGTH, but there is no per-request total byte/record budget. For each new parameter, fcgi_get_params() calls fcgi_hash_set(), which stores names and values in additional raw-malloc segments/bucket blocks (main/fastcgi.c:295-350). The accumulated hash is cleaned when the next request starts, not while the current request is still receiving parameters. A peer able to connect to a TCP FPM listener can therefore send many valid, distinct parameter pairs and keep the request open, growing a worker's memory before the PHP script is dispatched. These allocations are not governed by PHP's memory_limit. The default pool template binds to 127.0.0.1:9000, so this report is specifically about deployments where the FastCGI listener is reachable by an untrusted peer; it is not a claim that the default loopback configuration is remotely reachable. ### Expected behavior Please consider enforcing a cumulative per-request bound for FastCGI environment parameters (total bytes and/or count) and terminating the request when it is exceeded. A per-record maximum alone does not bound total allocation. ### Reproduction outline Against an isolated FPM instance with a TCP listener, send a FastCGI BEGIN_REQUEST, then a stream of FCGI_PARAMS records containing valid unique name/value pairs without sending the terminating empty FCGI_PARAMS record. Observe whether the worker's RSS grows with the accumulated parameters while the request remains in the parsing phase. I have traced this statically in the referenced source; I have not run this outline against a compiled build. ### Related issue [#16042](https://github.com/php/php-src/issues/16042) reports an FPM behavior when environment parameters are split across FastCGI records. This report concerns the separate lack of a cumulative allocation bound for complete, valid parameters.