PHP-FPM worker SIGSEGV: `run_time_cache` map_ptr offset beyond `CG(map_ptr_last)` when a class is reached through the CE cache

OPcache synchronises the SHM-side allocation counter ZCSG(map_ptr_last) with the worker's CG(map_ptr_last) in these places:

• zend_accel_load_script() — ext/opcache/zend_accelerator_util_funcs.c (if (ZCSG(map_ptr_last) > CG(map_ptr_last)) zend_map_ptr_extend(...))
• zend_accel_inheritance_cache_get() / _add() — ext/opcache/ZendAccelerator.c
• persisting — ext/opcache/zend_persist.c (extend → ZEND_MAP_PTR_NEW() → publish ZCSG(map_ptr_last) = CG(map_ptr_last), all under the SHM lock)

The CE cache fast path in zend_lookup_class_ex() (Zend/zend_execute_API.c) does not:

if (ZSTR_HAS_CE_CACHE(name) && ZSTR_VALID_CE_CACHE(name)) {
    ce_cache = GC_REFCOUNT(name);
    ce = GET_CE_CACHE(ce_cache);
    if (EXPECTED(ce)) {
        return ce;      /* no zend_map_ptr_extend() here */
    }
}

ZSTR_VALID_CE_CACHE() (Zend/zend_types.h) bounds-checks only the index of the CE cache slot itself. It does not validate the run_time_cache offsets of the methods of the class it returns. The interned string that carries the CE cache offset lives in SHM and is shared by every worker, so as soon as one worker fills the slot via ZSTR_SET_CE_CACHE_EX() (in zend_accel_inheritance_cache_get() in ext/opcache/ZendAccelerator.c, and in ext/opcache/zend_accelerator_util_funcs.c), every other worker sees it immediately, including workers that have not synchronised yet.

The order that produces the crash:

1. Worker B loads a script from SHM and extends up to the ZCSG(map_ptr_last) of that moment (measured: CG(map_ptr_last) = 20906).
2. Worker A links class C (ZEND_ACC_CACHEABLE) and persists it into SHM through zend_accel_inheritance_cache_add(). It allocates slots 20906, 20907, … for the run_time_cache of C's methods, publishes ZCSG(map_ptr_last), and writes the SHM zend_class_entry into the CE cache slot of C's name.
3. Worker B calls C::method(). zend_lookup_class_ex() returns immediately through the CE cache fast path (no extend).
4. The run_time_cache offset of C::method (slot 20907) is outside B's CG(map_ptr_last). Since ZEND_MAP_PTR_GET() does not bounds-check, B reads the uninitialised part of the allocation described by CG(map_ptr_size) (rounded up to 4096-entry granularity).
5. The value read is non-NULL garbage (measured: 0x4), so zend_init_func_run_time_cache() (Zend/zend_execute.c) skips initialisation and that garbage becomes EX(run_time_cache).
6. With an observer registered, _zend_observe_fcall_begin() (Zend/zend_observer.c) dereferences run_time_cache[zend_observer_fcall_op_array_extension] and segfaults.

We captured one core on PHP 8.4.25 and two on PHP 8.2.33. The one below is from 8.4.25, with debug symbols:

#5  <signal handler called>
#6  zend_observer_fcall_begin_specialized (allow_generator=false, execute_data=0xffff8a212210)
                                                     at Zend/zend_observer.h:92
#7  ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER ()            at Zend/zend_vm_execute.h:2115
#8  execute_ex (ex=0xffff8a212210)                    at Zend/zend_vm_execute.h:58972
#9  zend_execute (op_array=0xffff8a261200, return_value=0x0)
                                                     at Zend/zend_vm_execute.h:64349
#10 zend_execute_script (type=8, retval=0x0, file_handle=0x0)
                                                     at Zend/zend.c:1937
#11 php_execute_script_ex (primary_file=0x0, retval=0x0)
                                                     at main/main.c:2577
#12 php_execute_script (primary_file=0xfffff57380f0)  at main/main.c:2617
#13 main ()                                          at sapi/fpm/fpm/fpm_main.c:1942

Frames #0-#4 are the tracer's crash handler catching SIGSEGV and re-raising it with raise(). That is why the siginfo stored in the core describes the re-raised signal (si_code = SI_TKILL); the original faulting address is derived from the slot value as shown below. In production the crash handler itself reports si_addr = 0x14, which matches that derivation.

Values read from the three cores:

In all three, slot index == CG(map_ptr_last) + 1 — exactly one entry past the live range — while ZCSG(map_ptr_last) is far ahead of the worker. ce_flags = 0x421288 is ZEND_ACC_IMMUTABLE | ZEND_ACC_LINKED | ZEND_ACC_CACHED, i.e. a class placed into SHM through the inheritance cache.

The decisive detail is that op_arrays from the same file fall on different sides of the boundary:

• 8.4.25 core: the caller repro_f1307(), a file-scope function in the same /repro/app/c1307.php, is slot 27467 → in range. The crashing method ReproC1307::m0 is slot 27469 → out of range.
• 8.2.33 core A: the script's own op_array is slot 20905 → in range. The class method is slot 20907 → out of range.

So the worker did extend far enough for the file it loaded, and only the method slots that another worker allocated afterwards through the inheritance cache are out of range.

This does not reproduce every time: it is roughly once every 100-300 pool starts. We could not reproduce it with a short self-contained script — it needs several workers racing to fill a cold SHM.

Setup

• OPcache enabled. No JIT, no preload, no opcache.file_cache.
• An extension that registers an fcall observer is loaded (anything calling zend_observer_fcall_register(); we used the Datadog PHP tracer 1.23.3. zend_test.observer.enabled=1 should be equivalent).
• A single pool. No per-pool php_admin_value[extension] — the precondition of #23355 is not present.

[www]
listen = 127.0.0.1:9000
pm = static
pm.max_children = 28
pm.max_requests = 10000
catch_workers_output = yes

opcache.enable=1
opcache.memory_consumption=64
opcache.interned_strings_buffer=4
opcache.max_accelerated_files=20011
opcache.max_wasted_percentage=1
opcache.file_update_protection=0

Code: generate 3,000 PHP files, each with a class that uses extends.

<?php
require_once __DIR__ . '/base.php';   // abstract class ReproBase { public static function baseStatic(int $x): int { … } }
class ReproC123 extends ReproBase {
    public static function s0(int $x): int { return parent::baseStatic($x) + 0; }
    public function m0(int $x): int { return self::s0($x) * 2; }
    /* s1..s5 / m1..m5 likewise */
}
function repro_f123(int $x): int { $o = new ReproC123(); return $o->m0($x) + ReproC123::s1($x); }

The entry point require_onces 40 of those files per request and calls each function and static method.

Run

1. Start php-fpm (starting from an empty OPcache SHM is essential).
2. From the moment it is up, send FastCGI requests with 60 concurrent clients (8 requests each, 480 requests in about 1.3 s).
3. While the burst runs, keep invalidating files by updating their mtime with touch so that scripts are re-persisted. Do not append to the files: they grow on every iteration, the op_array sizes change, and the crash rate drops.
4. Stop php-fpm and go back to 1.

At 0.3-0.9% per pool start, a few hundred to 1,500 iterations produce a handful of exited on signal 11 (SIGSEGV) lines. The crash always happens 0.2-2.0 s after the worker started.

Reproduction harness (generator script, minimal FastCGI client, load loop): https://gist.github.com/msfukui/dcf8c5721138ad1d053665ca71254425

Notes for reproducing

• Keep the pool's privilege drop. We reproduce this with the production-shaped layout: master started as root, user = www-data in the pool. Starting the master as a non-root user gave 0 crashes in 1,200 pool starts, and -R with user = root gave 0 in 600. We have not identified the mechanism behind that difference, but do not "simplify" the setup by removing the privilege change.
• Use fs.suid_dumpable = 2 to get cores. A worker that drops privileges is not dumpable under the default setting. We recommend this over touching the PHP side: calling prctl(PR_SET_DUMPABLE, 1) from FFI also works mechanically, but even once per worker it adds work inside the very window we are trying to hit, and with that hook in place we saw no crash in 350 pool starts.
• Do not let a previous php-fpm master survive between iterations. If an older master still holds the listening socket, the next iteration's requests are served by that already-warm process and you get zero crashes with no error of any kind. This cost us a full day of measurements. pkill -9 between iterations, wait until the port is free, and assert that exactly one master is running.
• The core does not land in chdir. PHP changes the working directory to the directory of the executing script during a request, so also look next to the entry point script.

A/B on the presence of the observer (same setup, only the observer changed)

Two experiments, same result. The 8.5 one uses a paired design: every iteration runs the "observer" arm and the "no observer" arm back to back, so host load drift hits both arms equally.

This experiment alone cannot tell whether the same out-of-range read also happens without an observer and merely stays latent, or whether the observer's overhead widens the race window.

We did not run this A/B on 8.4.25: that environment was used for the core dump, and its per-pool-start rate is lower than 8.5.10's (0.33% vs 0.86%), so a realistic number of iterations would not separate the arms. The code that constitutes the defect is identical across versions, and 8.4.25 does reproduce under the same conditions — that is where the core above comes from.

Measured (same harness throughout; the observed rate depends heavily on harness settings, so please read this as "it happens on every version" rather than as absolute numbers)

The 8.5.10 and 8.4.25 numbers come from the harness with the guard that makes sure php-fpm is really stopped between iterations. 8.4.25 also gave 10 crashes in 1,500 pool starts (0.67%) on the earlier harness. The 8.2.33 number is from that earlier harness too, which appended to the files on every invalidation and may therefore understate the rate (i.e. it is a lower bound).

8.5.10 is the sury.org package (in PHP 8.5 OPcache ships with the core, there is no separate package) plus the Datadog PHP tracer 1.23.3.

Static check: the four ingredients of the defect are identical from PHP-8.1 to master (8.6.0-dev).

#15040 (25d761623c, moving the internal-function run-time cache to a separate area), which resolved #23355, does not cover this path — which is what reproducing on 8.4 shows.

Measured on PHP 8.5.10. (The report is centred on 8.4.25, but verifying workarounds needs the version with the highest per-pool-start rate: 0.86% on 8.5.10 versus 0.33% on 8.4.25.) Every iteration runs the "no workaround" arm and the "with workaround" arm back to back, so host load drift hits both arms equally. Nothing about how these workarounds act is version-specific: they either fill the SHM before traffic arrives, or they remove the observer.

Preload produced no crash in 450 pool starts, but the baseline arm produced only 2 crashes over the same period, so this arm is underpowered rather than proven. Its mechanism is the same as the warm-up (fill the SHM before traffic arrives), so the result is at least consistent.

OPcache parameters do not remove the defect, but they move the exposure up and down. They are worth listing because they explain why the rate varies so much between environments.

In other words, environments with a small interned strings buffer, or one that has hit its key limit, are less likely to run into this bug.

These involve design decisions, so we only sketch directions.

1. Synchronise in the CE cache fast path: when zend_lookup_class_ex() returns an SHM class from the CE cache, extend if ZCSG(map_ptr_last) > CG(map_ptr_last), as zend_accel_inheritance_cache_get() already does. This needs a hook on the OPcache side.
2. Bounds-check ZEND_MAP_PTR_GET(): at least assert offset < CG(map_ptr_last) in debug builds. If an out-of-range offset could be treated as NULL, zend_init_func_run_time_cache() would initialise the cache properly and the failure would be safe.
3. Reorder the publication of the CE cache slot: only publish the SHM class entry into the CE cache once the map_ptr offsets of that class's methods are valid for every worker.

One note on the extension side: there are implementations that trust the slot contents after only a non-NULL RUN_TIME_CACHE() check and write to it (we verified this in the Datadog PHP tracer), so this defect can lead to memory corruption, not just a read crash.

We searched php-src issues for map_ptr / run_time_cache / observer related terms to check for duplicates. We found no existing report that describes this mechanism.

• #9396 (open) — "PHP-FPM segfaults with Opcache enabled with Late Static Binding". This may well be the observer-less manifestation of the same bug. FPM only, OPcache-dependent, "in production core dumps other handlers in Zend/zend_vm_execute.h crash the same way", and no minimal reproduction — all of which fits this mechanism (garbage obtained by an out-of-range read is used as the run_time_cache, and whichever handler dereferences it first is where it crashes).
• #18147 (closed) — a crash through zend_lookup_class_ex on 8.4.5 / FPM / OPcache. Possibly the same thing, but after "This stack trace isn't very telling" it was suspended for lack of information. This report supplies what was missing: a reproduction, core dumps, and the invariant being violated.
• #23355 (open) — the same family of defect (a map_ptr offset persisted into SHM means something else to the reader, made visible by an observer), but a different arming path. That one requires multiple pools plus per-pool php_admin_value[extension], and was reported as not applying to 8.4. This one needs nothing but plain multi-worker FPM with OPcache, and reproduces on 8.4.25.
• #9871 (closed / fixed) — the crash site is exactly the same (_zend_observe_fcall_begin → ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER), but the cause was a user class inheriting an internal method, and it reproduced deterministically in 12 lines. The fix is in 8.4.25.
• #13817 (closed / fixed) — "Segmentation fault for enabled observers after pass 4" (from an optimizer pass). #13772 (closed / fixed) — a JIT-only EX(opline) problem. Both are different causes, and this issue still reproduces on 8.4.25, which contains both fixes.
• #23050 (open) — a case where EX(run_time_cache) is NULL (no OPcache, no JIT, single process). Similar symptom class, different problem.