fix(report): keep an out-of-range entry point from aborting synthesis

[r0ny123]

The Fuzzing workflow crashed fuzz_synthesis:

error: 'I' format requires 0 <= number <= 4294967295
  File "src/smda/synthesis/PeSynthesizer.py", line 411, in _buildMinimalOptionalHeader
    struct.pack_into("<I", opt, 16, entry_rva)

libFuzzer exited 77 after 116,018 executions having added 26 new units, which is the shape of newly reached coverage finding an old defect rather than of a new one being introduced.

Root cause

_resolveFunctionOffsets caps how far apart a report's functions may sit (MAX_IMAGE_SIZE), and that cap is what keeps every RVA derived from them inside a header field. The entry point is not a function offset, so the cap never sees it: a report may name an oep arbitrarily far from the image being rebuilt, and it reached the header packers unchecked.

Two of the three backends packed it anyway:

backend	field	width	before
PE	AddressOfEntryPoint	32-bit RVA	raises, losing the whole image
ELF32	e_entry	32-bit	silently truncates, entry ends up aimed elsewhere
ELF64	e_entry	64-bit	fine
Mach-O	LC_MAIN	—	already correct: drops the command when the entry falls outside the text segment

The ELF32 case is the same defect one step quieter. Its bound was checked against the 64-bit space (MAX_ADDRESS_VALUE) on both branches while the 32-bit branch packs <I, so a report with oep = 2**64 - 1 produced e_entry = 0xffffffff and no complaint.

Fix

Both fall back to .text — which is what a report carrying no oep at all already gets, and what the Mach-O synthesizer has always done for an entry outside its text segment. Losing the entry-point field is a much smaller loss than losing the image, and every other out-of-range report input in these modules (sparse string ranges, overlapping IAT slots, oversized section spans) already warns and continues.

An entry past the end of the 64-bit address space still raises. base_addr and oep can each pass deserialization on their own and still sum past the end of the space, which only this derivation sees, and that describes no image at all — there is nothing to approximate.

The relative-or-absolute reading of oep had been copied verbatim into all three backends, so it moves to BinarySynthesizer._resolveEntryPoint and the next backend inherits the bound along with the reading. The reason the value is unbounded is now documented where it is produced rather than in one of the three places that consume it.

Sweep

The class is "a report-derived integer reaching a fixed-width header pack without a width check". The other report integers that reach a header pack — base_addr, binary_size, identified_alignment — were driven to 2**64 - 1 across three formats and both word sizes. No second instance; oep was the only one no span check bounded.

Not from the branch that found it

The failing fuzz run was on an unrelated AArch64 branch that flips one Mach-O config flag, and three independent things say the crash is not that branch's:

1. That flag is read in exactly one place, the AArch64 candidate manager. fuzz_synthesis never disassembles — it builds a report from JSON and synthesizes — so the flag is unreachable from that target.
2. The crash reproduces on master with the same traceback at the same line.
3. Fuzz (fuzz_synthesis) had passed on an earlier run of that same head. Same code, different seeds.

Tests

• tests/fuzz_regressions/synthesis_entry_point_beyond_rva_space_xored — the minimized reproducer (790 bytes, via fuzzing/minimize.py), pinned per that directory's convention. Verified to fail before the fix and pass after.
• Eight cases in SynthesisEntryPointTestSuite, four of which fail without the fix: the PE fallback, the ELF32 fallback, and the two _resolveEntryPoint readings. The other four guard what the fix must not change — a valid PE entry is still kept, a 64-bit ELF entry above 4 GiB is still written verbatim, and a report with no oep still aims at the first executable section.

Validation

ruff check / ruff format --check pass, ty check exit 0, full suite green on this branch rebased onto current master (1821 passed, 1 skipped, 2585 subtests), diff coverage 100% on all 24 changed lines against upstream/master.

This is independent of #299 and #300 and merges cleanly against either.

The ty commit at the tip

The last commit on this branch is #302's fix, cherry-picked unchanged.

Master fails Code Quality on its own right now: 572acd7 bumped ty to 0.0.74, and its new unsound-return-statement / unsound-assignment rules become errors under [tool.ty.rules] all = "error". That is 41 errors across 15 files, none of which this PR touches — so every PR opened against master inherits a red check that says nothing about its own diff.

Carrying #302's commit here means this PR's CI reflects only this PR's work. It is the same commit, unmodified, so the moment #302 lands this one is empty and falls out on rebase — there is nothing to untangle later. If you would rather look at this branch without it, merge #302 first and I will drop it.

Checked against ty 0.0.74 itself rather than whatever an older local pin resolves to: on master it exits 1 with 41 errors, on this branch it exits 0 with none.