Sleigh segfaults on short inputs for JVM, NDS32 and SPARC

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Three Sleigh language definitions segfault on short byte sequences. They are
almost certainly three separate defects and can be split if that is easier to
triage — they are together here because they came out of one survey and share a
shape: a small input, no exception, the process gone.

All three reproduce on 559aacdc, which is master at the time of writing, and
each is a bare translate call with no other state.

1. JVM — tableswitch

pypcode.Context("JVM:BE:32:default").translate(
    bytes.fromhex("aa873b8e6f50b409"), 0x1001,
    max_instructions=99999, max_bytes=8,
    flags=pypcode.TranslateFlags.BB_TERMINATING)

0xaa is tableswitch; 0xab (lookupswitch) fails the same way. Eight bytes.

2. NDS32

pypcode.Context("NDS32:LE:32:default").translate(
    bytes.fromhex("26095d273add"), 0x1010,
    max_instructions=99999, max_bytes=6,
    flags=pypcode.TranslateFlags.BB_TERMINATING)

Six bytes.

3. SPARC

pypcode.Context("sparc:BE:32:default").translate(
    bytes.fromhex("1728394a5b6c7d8e9fb0c1d2b01e0019"), 0x14,
    max_instructions=99999, max_bytes=16,
    flags=pypcode.TranslateFlags.BB_TERMINATING)

This one needs the whole run in a single translate call — no individual word
in that sequence crashes on its own, which I checked.

How much weight to put on these

Less than on the PowerPC report I opened alongside this one, and I would rather
say so than oversell. That case is an ordinary vaddubm that a compiler emits,
and it corrupts the heap. These three are short sequences that do not correspond
to code any toolchain produces, so they are robustness findings rather than
something a user meets on real input.

They still seem worth having. A lifter is routinely pointed at binaries whose
provenance is unknown, and there the distinction between "valid code" and
"arbitrary bytes" does not hold — the caller cannot know which it has until
after the lift, and a segfault gives no opportunity to skip the block.

I have not attempted fixes and am not proposing any. Happy to retest against a
patch.

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

A fourth language belongs on this list, and unlike the other three it is one people actually load: MIPS little-endian.

import pypcode
pypcode.Context("MIPS:LE:32:default").translate(bytes.fromhex("55427a8baf962576edfdd546"), 0)

Twelve bytes, SIGSEGV, no exception, at any address. MIPS:LE:32:micro dies on the same input.

The interesting part is that it is byte-order specific — the same bytes through the big-endian definitions are clean:

MIPS:LE:32:default   SIGSEGV
MIPS:LE:32:micro     SIGSEGV
MIPS:BE:32:default   clean
MIPS:BE:32:micro     clean

Reduced by delta-debugging from a 128-byte input, on 559aacdc, which is master.

I have not established whether this is one of the defects already fixed by #288 or #289 rather than a fourth. MIPS has delay slots, so #288 is the obvious candidate, but I did not build either branch to check — worth doing before treating it as separate.

Found while accounting for every native crash in a large corpus sweep: 479 crashes over 746,966 analyses, of which SLEIGH parse-tree overruns are the second largest cause. The three languages already named here account for 115 of them and are reached only by synthetic inputs; this MIPS case came from a real collection, which is what makes it worth adding.

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Answering my own open question above: the MIPS case is not a fourth defect. It is #288, and it is the first instance of it that came from a real binary rather than a fuzz corpus.

Built master, #288, #289 and both together, and ran every case in this issue against each:

                          master    #288      #289      both
MIPS:LE:32:default        SIGSEGV   clean     clean     clean
MIPS:LE:32:micro          SIGSEGV   clean     clean     clean
MIPS:BE:32:*  (control)   clean     clean     clean     clean
JVM lookupswitch 0xab     SIGSEGV   SIGSEGV   BadData   BadData
JVM tableswitch           SIGSEGV   SIGSEGV   BadData   BadData
NDS32                     SIGSEGV   SIGSEGV   clean     clean
SPARC                     SIGSEGV   clean     clean     clean
PowerPC vaddubm (#292)    SIGABRT   SIGABRT   clean     clean

The shape of that table is the answer. #288 fixes MIPS and SPARC and nothing else; #289 fixes JVM, NDS32 and PowerPC. MIPS travels with SPARC, which is the delay-slot defect, not with the parse-tree ones.

The decode confirms it: those twelve bytes are lwl k0, 0x4255(k1) / jalx 0x8965abc / plu.ps f23, f31, f21. jalx is a delay-slot branch and plu.ps — MIPS-3D paired-single — has no p-code section, so PcodeBuilder::build throws through SleighBuilder::delaySlot and the handler then reads the walker whose frame has gone. Big-endian reads the same bytes as bnel with sw in the delay slot; sw has p-code, nothing throws, and the walker is restored normally. That is the whole of the byte-order asymmetry.

Post-fix the block truncates at jalx and returns 15 ops, keeping the earlier lwl, which matches #288's own test_partial_delay_slot_unimpl_failure.

One thing worth carrying to #288 and #289, which I have also said there: #289 makes this symptom disappear without fixing it. Under ASan the stack-use-after-return on sleigh.cc:388's newwalker is still reported on the #289 tree, identical to master; #289 grows ParserWalker::breadcrumb from int4[32] to int4[128], which resizes every frame holding a walker and changes what the dangling pointer lands on.