angr / angr/pypcode

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

Ouverte
#292 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
Langage dominant
C++
Étoiles
214
Forks
30
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

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.

```python
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.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.