memory_limit ja Out-of-Memory: mis toimub sees

Lühidalt: PHP Out-of-Memory viga tekib siis, kui skript tahab taotleda rohkem mälu, kui säte memory_limit lubab (vaikimisi: 128 MB päringu kohta). PHP katkestab päringu siis fataalse veaga ja koristab. Just see katkestamis- ja koristustee oli veaga CVE-2026-109618 puhul, mis on üks kahest PHP2Shelli turvaaugust. Alates versioonidest PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 on memory_limit pehme piir, mida täiendab kõva piir memory_hard_limit_percent.

Mida tähendab „Allowed memory size exhausted“?

Tuntud veateade kõlab mõtte poolest nii: „Allowed memory size of 134217728 bytes exhausted (tried to allocate …)“. Esimene arv on seatud piir baitides, siin 128 MB. Skript on seega püüdnud hõivata mälu üle selle piiri, näiteks suure faili laadimisel, hiiglasliku andmebaasipäringu korral või lõputu tsükliga.

Otsustajale oluline: piir kehtib PHP protsessi ja päringu kohta, mitte kogu serverile. See kaitseb serverit selle eest, et üksik vigane skript kogu mälu ära kasutaks. Kogukoormus tuleneb alles samal ajal töötavate workerite arvust. 20 PHP-FPM workeri korral, igaühel 256 MB piir, on see arvutuslikult üle 5 GB.

Kuidas PHP mälu loeb

PHP haldab päringute mälu oma mäluhalduriga, Zend Memory Manageriga. See toob operatsioonisüsteemilt suuremaid plokke ja jagab neid seespidiselt muutujatele, massiividele ja objektidele. Selle reserveeritud väärtuse vastu kontrollib PHP memory_limit. Mälu, mida laiendus taotleb otse operatsioonisüsteemilt, selles loendis käsiraamatu järgi ei esine.

Väärtusi saab koodis nähtavaks teha:

<?php
echo memory_get_usage(), PHP_EOL;       // skripti praegu hõivatud mälu
echo memory_get_usage(true), PHP_EOL;   // mäluhalduri reserveeritud; selle vastu kontrollib memory_limit
$liste = range(1, 200000);
echo memory_get_peak_usage(), PHP_EOL;  // seni suurim väärtus
unset($liste);
memory_reset_peak_usage();              // tipuväärtuse lähtestamine, alates PHP 8.2-st

Kuidas viidete loendus ja Garbage Collection mälu uuesti vabastavad, selgitab leht Mäluhaldus PHP-s.

Mis Out-of-Memory korral sees toimub

Lihtsustatult kulgeb mälukatkestus järgmiste sammudega:

1. Skript taotleb mälu, näiteks uue massiivielemendi jaoks või päringuandmete sisselugemisel.
2. Mäluhaldur kontrollib, kas taotlus ületab piiri.
3. Kui jah, annab PHP fataalse vea ja lahkub käimasolevast töötlusest kohe, ka pooleli oleva ülesande keskel.
4. Registreeritud shutdown-funktsioonid veel käivituvad; paljud rakendused logivad nende abil vea.
5. Lõpuks koristab PHP päringu ja vabastab selle mälu. Worker on seejärel järgmiseks päringuks valmis.

Delikaatne koht on samm 5. Koristamine peab hakkama saama andmestruktuuridega, mis olid katkestamise hetkel alles pooleldi loodud. Tavaline mälukatkestus ei ole PHP projekti turvapoliitika järgi turvaauk, kui piir lükkab taotluse tagasi ja lõpeb ainult praegune päring. CVE-2026-109618 puhul oli just see eeldus rikutud: php.net andmetel võis Out-of-Memory seisund PHP töö katkestada ajal, mil sisemised päringuandmed olid alles osaliselt lähtestatud, ja koristamine käsitles kehtetuid andmeid siis kehtivatena. Ekspluateerimise üksikasju me ei avalda; turvaauku käsitleb CVE-2026-109618.

Uus pehme ja kõva mälupiir

21.10.2026 turvaväljaannetega muutis PHP projekt käitumist. Käsiraamatu järgi on memory_limit sestsaadik pehme piir: taotluse, mis seda ületab, tohib enamasti veel lõpule viia, enne kui järgneb fataalne viga. Eraldi kõva piir piirab, kui kaugele see minna tohib.

Näide käsiraamatust: kui memory_limit=128M ja memory_hard_limit_percent=150, on kõva piir 192 MB. Käsiraamat nimetab direktiivi samas ka tunnuseks: kui PHP versioon seda ei tunne, mõjutavad seda CVE-2026-109618 ja CVE-2026-109619. Kiire test iga paigaldatud PHP versiooni jaoks:

php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
# bool(false) tähendab: direktiiv on tundmatu

Backportiga distributsioonipakettide puhul jääb paketi muudatuslogi otsustavaks tõendiks, nagu on kirjeldatud lehel PHP versiooni ja paigaseisu õige kontrollimine. Kontrollige lisaks PHP-FPM binaari eraldi, sest see võib olla teine versioon kui käsurea oma.

Mälupiirid ja PHP2Shell: mida adminnid nüüd silmas peavad

php.net ajutised meetmed CVE-2026-109618 vastu keerlevad peaaegu kõik mälu ja päringumahtude ümber. Need vähendavad riski, kuid ei asenda uuendust:

; FPM-pool, nt /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M        ; 32M, kui üleslaadimisi on vaja
php_admin_value[upload_max_filesize] = 6M  ; hoida post_max_size'ist väiksemana

Kolm punkti on seejuures otsustavad. Esiteks ei tohi ükski rakendus, kataloog ega muu pool uuesti lõplikku piiri seada; php.net nõuab selgesõnaliselt seda kontrolli. Teiseks vajab teenus, kus memory_limit=-1, piiri väljastpoolt, konteineri või cgroupi kaudu, php.net järgi kõige parem selliselt, et lõpetatakse ainult mõjutatud worker. RLIMIT_AS ja RLIMIT_DATA on php.net järgi sobimatud. Kolmandaks soovitab php.net piiranguid veebiserveris või puhverserveris päringu suuruse, väljade arvu, multipart-osade, päiste ja pesastussügavuse jaoks.

Kuidas piiri systemd-ga seada, on lehel Mälupiirangud systemd ja cgroupidega; püsilahendust igapäevaks kirjeldab memory_limit õige seadmine.

Kuidas PHP SOS konkreetselt aitab?

PHP paikamisteenuse kaudu tegutseme nii:

• Olemasoleva kontroll: Kogume serveris kõik PHP versioonid, eraldi CLI, FPM ja Apache'i mooduli kaupa, ning testime, kas parandatud versioon töötab.
• Mälupiiride korrastamine: Kontrollime, kus kõikjal memory_limit seatakse, ja seame pooli- ja süsteemipiirid nii, et need sobivad kokku.
• Üleminekuaja kindlustamine: Kus uuendus on veel blokeeritud, seame php.net meetmed täielikult ja ülekirjutamise vastu lukustatult.
• Tõendi esitamine: Saate versioonid, paketiseisud ja seadistuse enne ja pärast sekkumist kirjalikult.

Korduma kippuvad küsimused

Allikad

• PHP käsiraamat: tuumasätted (memory_limit, memory_hard_limit_percent)
• PHP käsiraamat: memory_get_usage()
• php.net: turvateated 21.10.2026