SEC: Detect multi-hop cyclic /Pages trees in _flatten to prevent SIGSEGV - #3847

Summary

_flatten() only checked if a /Pages kid directly referenced its own parent node (the single-parent check on line 1219). This missed multi-hop cycles such as A → B → C → A, where no node is its own immediate child.

A malformed PDF with such a cycle causes _flatten() to recurse until Python's RecursionError is raised. In production environments with partially-consumed C stacks (e.g. gunicorn workers), the native stack overflows before Python can intercept the recursion, resulting in SIGSEGV and a dead worker process — not a catchable Python exception.

Root cause

/Pages obj 2  →  /Kids [6 0 R, 3 0 R]
/Pages obj 3  →  /Kids [4 0 R]
/Pages obj 4  →  /Kids [5 0 R]
/Pages obj 5  →  /Kids [3 0 R]   ← cycle back to obj 3

len(reader.pages) on this PDF triggers the infinite recursion. The existing except RecursionError block is an unreliable backstop: it works in an isolated Python process but fails under a heavily-framed call stack.

Fix

Add a _seen_refs: set parameter to _flatten() that accumulates the (idnum, generation) of every /Pages indirect reference visited during traversal. Any reference seen a second time raises PdfReadError("Detected cyclic page references.") immediately, without relying on Python's recursion limit.

Test

test_cyclic_pages_tree constructs a minimal in-memory PDF reproducing the exact cycle above and asserts PdfReadError is raised when accessing reader.pages. The existing test_get_object_from_stream__size_limit test's match pattern was relaxed because that broken PDF also produces a cycle that is now detected earlier.

Reproduction

from pypdf import PdfReader

# PDF with /Pages loop: obj 3 → obj 4 → obj 5 → obj 3
pdf_bytes = open("page_loop.pdf", "rb").read()
reader = PdfReader(io.BytesIO(pdf_bytes), strict=False)
len(reader.pages)  # RecursionError / SIGSEGV before this fix