ARM:LE:32:v7 and v8 segfault translating a coprocessor STC word (v6 raises BadDataError)
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
調査の方向性
まず、746b69cd を指定した pypcode.Context("ARM:LE:32:v7").translate でクラッシュを再現し、次に SLEIGH ベースのデコーダーにおける ARM v6、v7、v8 の変換パスを比較します。v7 と v8 が BadDataError を発生させる代わりに SIGSEGV で終了する理由を追跡し、再現コードがクラッシュせず期待される例外で完了することを確認します。
索引モデルが issue の本文から書いたものです。
説明
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
ARM:LE:32:v7 and ARM:LE:32:v8 segfault translating a single 4-byte word.
ARM:LE:32:v6 rejects the same word cleanly with BadDataError, so the correct
failure mode already exists next door in the same processor family.
Reproducer
import pypcode
pypcode.Context("ARM:LE:32:v7").translate(bytes.fromhex("746b69cd"), 0x1000)
Four bytes, one call, no flags, no other state. Deterministic: 10/10 runs,
SIGSEGV (exit 139). Same for ARM:LE:32:v8.
Expected behaviour
A raised exception, not a crash. BadDataError is the right outcome here — the
word is not valid code for this language, and ARM:LE:32:v6 already returns
exactly that for the identical input:
BadDataError: r0x00001000: Unable to resolve constructor
The distinction matters to a caller, not just aesthetically. An exception is
catchable: a tool sweeping an image can skip the offending block and carry on.
SIGSEGV takes the process out with no opportunity to recover, no partial
results, and no indication of which address was responsible. So the ask is that
v7/v8 fail the way v6 does, whatever the underlying cause turns out to be.
Behaviour across the ARM variants
Each in its own child process, so the matrix survives:
import subprocess, sys, pypcode
WORD = "746b69cd" # little-endian 0xcd696b74
CHILD = "import pypcode,sys; pypcode.Context(sys.argv[1]).translate(bytes.fromhex(sys.argv[2]), 0x1000)"
print(f"pypcode {pypcode.__version__}")
for lang in ("ARM:LE:32:v5", "ARM:LE:32:v6", "ARM:LE:32:v7",
"ARM:LE:32:v8", "ARM:LE:32:Cortex", "ARM:BE:32:v7"):
rc = subprocess.run([sys.executable, "-c", CHILD, lang, WORD], capture_output=True).returncode
print(f" {lang:18} {'SIGSEGV' if rc in (-11, 139) else f'ok (rc={rc})'}")
| language | result |
|---|---|
ARM:LE:32:v5 |
ok — decodes as stclgt p11,cr6,[r9,#-0x1d0]! |
ARM:LE:32:v6 |
BadDataError: r0x00001000: Unable to resolve constructor |
ARM:LE:32:v7 |
SIGSEGV |
ARM:LE:32:v8 |
SIGSEGV |
ARM:LE:32:Cortex |
ok — decodes as Thumb (ldr / ldmia) |
ARM:BE:32:v7 |
ok — different word under the other byte order |
The word
0xcd696b74 decodes (per ARM:LE:32:v5) as:
stclgt p11, cr6, [r9, #-0x1d0]!
A coprocessor store, predicated GT, pre-indexed with writeback, targeting
p11 — the VFP double-precision coprocessor. Field breakdown:
cond=0xc(GT) op=0b110 P=1 U=0 D=1 W=1 L=0
Rn=r9 CRd=c6 coproc=p11 imm8=116 (byte offset 464)
The split lines up with VFP modelling: v5 has no VFP model and takes it as a
plain STCL; v6 refuses it; v7/v8 model VFP/NEON and die. That v6 raises
where v7 crashes is the part I would weight most — it suggests something in the
newer VFP/NEON decode path rather than a general gap in coprocessor handling.
Where the bytes came from
Not synthesised. The word occurs five times inside kallsyms_names — the
compressed kallsyms symbol-name table — in Debian's linux-image-2.6.37-2-versatile
(armel). The crashing decode is at 0xc02b6410, kallsyms_names + 0x8e70. That
build's System.map types kallsyms_names as T, so the table sits in the text
region, and a sweep of executable ranges decodes it as instructions.
To be exact about the artifact: Debian's regular (non-dbg) armel package ships a
compressed /boot/vmlinuz, not an ELF, so the bytes were read from the
decompressed kernel image out of that zImage — stock Debian content, in a
container rebuilt locally. The word does not appear in the armhf -dbg images I
also have (4.9.0-19-armmp, 4.18.0-3-armmp), so this is specific to that
build, and I would not want to overstate how common it is.
That is the practical impact: a consumer pointed at an arbitrary ARM binary
cannot know whether a given word is code before lifting it, and a segfault gives
no opportunity to skip the block. Refusing invalid input is fine — v6 already
does exactly that.
Environment
pypcode 4.0.0 (PyPI wheel, cp313-cp313-manylinux_2_27_x86_64)
python 3.13.7
platform Linux-5.10.16.3-microsoft-standard-WSL2-x86_64-with-glibc2.35
machine x86_64
Tested against the 4.0.0 release wheel, not against master — happy to
retest there or against a candidate fix if that is useful.
Related
Same class as #293 (segfaults on short inputs for JVM, NDS32, SPARC) and #292
(PowerPC vaddubm heap corruption), but a different language and not covered by
either, so filing separately. Unlike the three in #293, this word is not a
synthetic sequence — it occurs in a real distribution kernel.
- 主要言語
- C++
- スター
- 222
- フォーク
- 33
- 平均マージ
- 7時間 13分
- マージ済み PR（30日）
- 7
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
angr/pypcode のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 28/100
-
Update to Ghidra 12.1.2再び着手できるかも @mborgerson が 126 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンenhancement
-
enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
ROCm/rocm-libraries#14027 ·
メンテナーはふだん 2 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
Qiskit/qiskit-aer#2487 ·
メンテナーはふだん 1 日以内に返信
-
GUI
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
qbittorrent/qBittorrent#25104 ·
メンテナーはふだん 2 日以内に返信
-
P2: A timed rotation maneuver does nothing on a ship that had an earlier timed lateral maneuverオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
scp-fs2open/fs2open.github.com#7914 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 2 日以内に返信