Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[FPM] Bound cumulative FCGI_PARAMS allocation per request

Đang mở
#24,114 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c, php
Lĩnh vực
backend, networking, security

Hướng nghiên cứu

Start in main/fastcgi.c, especially fcgi_read_request() at lines 1110-1132 and fcgi_get_params()/fcgi_hash_set() at lines 295-350. Reproduce with an isolated TCP FPM listener using the described stream of valid parameters without the terminating empty record. Done means an exceeded cumulative parameter bound terminates the request rather than allowing unbounded allocation during parsing.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Description

The FastCGI request reader has 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 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 only when the next request starts, not while the current request is still receiving parameters.

A peer able to connect directly to a TCP FPM listener can 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; this report therefore applies only when an untrusted peer can reach the FastCGI listener, not to the default loopback-only deployment behind a properly configured web server.

Validation

Reproduced against a locally built FPM from php-src commit 63b0af4a5c400d93510dca7aa998769609fdc26c. With the pool's memory_limit set to 1M, I sent a BEGIN_REQUEST followed by 100,000 distinct, valid name/value pairs in 31 FCGI_PARAMS records (1,800,000 parameter bytes), and withheld the terminating empty FCGI_PARAMS record. The worker remained in request parsing and its RSS grew from about 6,412 KiB to 9,844 KiB. Current master 68292bc476c709ff7ac0632d963af0e379dc4a53 has byte-identical main/fastcgi.c (blob a393283fcb0b8a156796fc7c21f07d2052737f91).

Expected behavior

Enforce a cumulative per-request bound for FastCGI environment parameters (total bytes and/or count) and terminate the request when 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 worker RSS while the request remains in parsing.

Related issue

#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.

Ngôn ngữ chính
C
Star
40.7k
Fork
8.3k
Merge trung bình
2 ngày 18 giờ
Pull request đã merge (30 ngày)
159

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của php/php-src

Tất cả issue của php/php-src

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.