BUG: SIGSEGV when creating an array from a deeply nested structured dtype

[eGkritsis]

Describe the issue:

Creating an array from a sufficiently deeply nested structured dtype can terminate the Python process with SIGSEGV instead of raising a catchable exception.

The structured dtype itself can be constructed successfully at very large nesting depths. The crash occurs when the dtype is subsequently used to create an array, for example with numpy.zeros().

On my test system with NumPy 2.5.2, the crash occurs at approximately 43,000+ levels of nested structured dtype. The exact threshold is environment-dependent.

The same behavior was also reproduced with NumPy 2.4.4.

I also tested the .npy loading path with a crafted header describing the same nested dtype. With the default max_header_size=10000, numpy.load() rejected the oversized header before reaching the crashing path on my tested configuration.

Reproduce the code example:

import numpy as np

depth = 44000

dt = np.dtype([("v", "i4")])

for _ in range(depth):
    dt = np.dtype([
        ("v", "i4"),
        ("next", dt),
    ])

print("dtype constructed successfully")
print("dtype itemsize:", dt.itemsize)

# SIGSEGV on my test system
arr = np.zeros(1, dtype=dt)

print("array constructed successfully")

Error message:

The process terminates with `SIGSEGV` and does not raise a Python-level exception.

Observed output:


dtype constructed successfully
dtype itemsize: 176004
Segmentation fault (core dumped)


### GDB reports:

Thread 1 "python" received signal SIGSEGV, Segmentation fault.

Relevant portion of the GDB backtrace:


#43646 0x00007ffff6b9c8c8 in PyArray_NewFromDescr_int ()
   from /tmp/numpy-poc-venv/lib/python3.12/site-packages/numpy/_core/_multiarray_umath.cpython-312-x86_64-linux-gnu.so
#43647 0x00007ffff6b9e8cb in PyArray_Zeros_int ()
   from /tmp/numpy-poc-venv/lib/python3.12/site-packages/numpy/_core/_multiarray_umath.cpython-312-x86_64-linux-gnu.so
#43648 0x00007ffff6bf8c0d in array_zeros ()
   from /tmp/numpy-poc-venv/lib/python3.12/site-packages/numpy/_core/_multiarray_umath.cpython-312-x86_64-linux-gnu.so
#43649 0x0000000000581dad in ?? ()
#43650 0x0000000000549835 in PyObject_Vectorcall ()
#43651 0x00000000005d7429 in _PyEval_EvalFrameDefault ()
...
#43661 0x0000000000658345 in _start ()

Python and NumPy Versions:

2.5.2
3.12.3 (main, Jul 15 2026, 23:46:41) [GCC 13.3.0]

Tested and reproduced on:

• NumPy 2.5.2
• Python 3.12.3
• x86-64 Linux
• glibc 2.39
• Linux 7.0.0-30-generic

The same crash was also independently reproduced with NumPy 2.4.4 on the same general environment.

Runtime Environment:

[{'numpy_version': '2.5.2',
  'python': '3.12.3 (main, Jul 15 2026, 23:46:41) [GCC 13.3.0]',
  'uname': uname_result(system='Linux', node='ubuntu', release='7.0.0-30-generic', version='#30~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug  7 13:27:52 UTC 2', machine='x86_64')},
 {'simd_extensions': {'baseline': ['X86_V2'],
                      'found': ['X86_V3'],
                      'not_found': ['X86_V4', 'AVX512_ICL', 'AVX512_SPR']}},
 {'ignore_floating_point_errors_in_matmul': False},
 {'architecture': 'Haswell',
  'filepath': '/tmp/numpy-poc-venv/lib/python3.12/site-packages/numpy.libs/libscipy_openblas64_-61654e39.so',
  'internal_api': 'openblas',
  'num_threads': 16,
  'prefix': 'libscipy_openblas',
  'threading_layer': 'pthreads',
  'user_api': 'blas',
  'version': '0.3.34.0.0'}]

How does this issue affect you or how did you find it:

I found this issue as part of ongoing research into uncontrolled recursion, resource consumption, and process-crashing conditions in data-processing and serialization libraries.

I have reported close to 15 bugs involving uncontrolled recursion, denial of service, and process crashes across different libraries and software components. This work is also directly related to our published USENIX WOOT '26 paper:

“Evading and crashing anti-malware solutions via data collection overloading during analysis serialization”

by Evgenios Gkritsis, Constantinos Patsakis, and George Stergiopoulos.

In that work, we introduce Telemetry Complexity Attacks (TCAs), which demonstrate how adversarially generated deeply nested or oversized data can stress serialization, storage, and visualization components in malware analysis and EDR systems, potentially resulting in denial-of-analysis conditions.

This NumPy issue follows the same broader research direction: examining how deeply nested data structures can cross recursion or resource boundaries and cause uncontrolled behavior. In this case, a valid deeply nested structured dtype can exhaust the native call stack during array construction and terminate the Python process with SIGSEGV.

I am reporting it because the behavior is an unrecoverable native crash where a controlled exception or explicit depth/resource limit would be preferable.

[ngoldbaum]

Here is a reproducer that crashes on main on any system. The reproducer in the issue description relies on Linux-specific details and passes on my Mac.

import threading
import numpy as np

def main():
    dt = np.dtype([("v", "i4")])
    for _ in range(50_000):
        dt = np.dtype([("v", "i4"), ("next", dt)])
    np.zeros(1, dtype=dt)

# 1 MiB thread stack
threading.stack_size(1 << 20)
t = threading.Thread(target=main)
t.start()
t.join()
print("no crash")

The fix is to add Py_EnterRecursiveCall guards to C internals that are triggering the overflows. This should be happening everywhere we do recursion in C.

[eGkritsis]

Thanks for reproducing.
This is actually a class of issues I’ve been reporting quite a lot recently: uncontrolled recursion, native stack overflows, and related DoS conditions across data-processing libraries.

Depending on the application-level reachability, I think this could potentially be around CVSS 3.1 7.5 (High).

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N%2FAC:L%2FPR:N%2FUI:N%2FS:U%2FC:N%2FI:N%2FA:H&version=3.1

[ngoldbaum]

See our security policy if you want to report security issues. That said, there are quite a few public ways to segfault both CPython and NumPy, so I doubt people would consider this a security issue.

https://numpy.org/doc/stable/reference/security.html

[LeonxLJX]

I'd like to take this one. SIGSEGV on numpy.zeros((1,), dtype=deeply_nested_structured_dtype) is a hard crash from C-level recursion or unchecked stack growth — the dtype-construction walks the nested descriptors recursively, and the array allocation then recursively walks them to compute element size. At sufficient depth the stack overflows.

Root cause (best read). In numpy/core/src/multiarray/descriptor.c the PyArray_DescrNew / PyArray_DescrConverter functions recurse into nested field-dtype children to clone / compute size. The recursion has no depth limit. Python's sys.getrecursionlimit() is a Python-only limit; the C stack (per-thread, much smaller — typically 1-8 MB) is the actual limit for C-level recursion, and a 2000-level nested dtype blows it.

Alternatives I considered: (a) Iterative descent in the dtype walker with an explicit depth counter (correct fix, IMO). (b) Catch SIGSEGV and re-raise as MemoryError / ValueError (hides the bug, dangerous). (c) Document the limitation: 'numpy supports nested dtypes up to depth N' (workaround, fragile).

Suggestion to maintainer: (a) is the right shape — convert the recursive C walk to an iterative one with an explicit depth limit (return ValueError above ~256 levels). Two questions: (i) is the dtype-construction walk the same recursive path as the array-allocation walk? If so the fix touches both. (ii) Does numpy.recfromcsv / numpy.lib.recfunctions have a parallel recursive path that needs the same treatment? (claiming via @LeonxLJX)

[rgommers]

This isn't a security issue, because the default of max_header_size=10000 doesn't trigger it - that's very clear-cut. Either way, once something is public, it is no longer helpful to report it privately

With the default max_header_size=10000, numpy.load() rejected the oversized header before reaching the crashing path on my tested configuration.

Even if it would be triggered with the default setting, we'd likely consider it a regular bug, because our security policy states:

NumPy structured dtypes allow for a large amount of complexity. Fortunately, most code fails gracefully when a structured dtype is provided unexpectedly. However, code should either disallow untrusted users to provide these (e.g. via .npy files) or carefully check the fields included for nested structured/subarray dtypes.