Translating vaddubm on big-endian PowerPC corrupts the heap and aborts

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Translating a single ordinary AltiVec instruction corrupts the heap and aborts
the process. Four bytes are enough, and the input is valid PowerPC — not
malformed or random data.

import pypcode
pypcode.Context("PowerPC:BE:32:default").translate(
    b"\x10\x00\x00\x00", 0x1000,
    max_instructions=99999, max_bytes=4,
    flags=pypcode.TranslateFlags.BB_TERMINATING,
)

The process dies with SIGABRT and glibc reports heap corruption — variously
free(): invalid size and corrupted size vs. prev_size, which indicates an
out-of-bounds write rather than a bad read.

On big-endian PowerPC, 10 00 00 00 decodes as vaddubm v0,v0,v0 — vector add
unsigned byte modulo, an unremarkable AltiVec instruction that a compiler will
emit for ordinary vectorised code.

What I verified

language	result
PowerPC:BE:32:default	SIGABRT, heap corruption reported by glibc
PowerPC:BE:64:default	SIGABRT, heap corruption reported by glibc
PowerPC:LE:32:default	no abort — those bytes are not vaddubm in this byte order

So the trigger tracks the instruction rather than the language variant, as one
would expect.

This is current master: the checkout used is 559aacdc, which is master at
the time of writing, and it also reproduces on the released 4.0.0 wheel from
PyPI in a clean virtual environment, so it does not depend on a source build.

Why it is worth attention

Any consumer that lifts PowerPC through Sleigh can be killed outright by four
bytes of legitimate input, with no exception to catch and no opportunity to skip
the block. It surfaced during a survey of a large binary corpus, where it
accounted for a small number of objects only because most PowerPC there routes
through a different lifter — the object count understates the exposure rather
than bounding it.

I have not attempted a fix, and I am not proposing one here; the report is the
contribution. Happy to test a patch against the same input if that helps.