pa-risc Context retains memory without bound on adversarial input

未关闭
  • 哪里不对？
#291 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
28/100
Issue 类型
缺陷
描述清晰度
需要澄清
活跃度
活跃
技术栈
cpp, python
领域
devtools, reverse-engineering

调研方向

首先针对 559aacd 运行提供的 Python 复现程序，然后检查 Context.translate 和 angr/engines/pcode/lifter.py，以了解长期存留的 context 路径。将 pa-risc 扫描与列出的对照项和 400 字节区间进行比较；当 retention 机制得到确立，并且报告的 bad_alloc 行为有可重复的回归检查时，即视为完成。

由索引模型根据 Issue 内容生成。

描述

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

A long-lived Context for pa-risc:BE:32:default grows until it exhausts the
process, on synthetic input, where every other p-code language tested plateaus.
I can reproduce it deterministically but I cannot explain it, so this is a
report rather than a pull request — see the "what I could not establish"
section, which is the reason.

Reproducer

One Context, 65,536 distinct 5000-byte windows at distinct addresses, window
i being the four bytes i << 16 big-endian repeated:

import os, resource, sys, pypcode

WINDOW, MAXI = 5000, 99999
LANG = "pa-risc:BE:32:default"
ctx = pypcode.Context(LANG)
_s = os.open("/proc/self/statm", os.O_RDONLY)
rss = lambda: int(os.pread(_s, 128, 0).split()[1]) * 4096
_, hard = resource.getrlimit(resource.RLIMIT_AS)
with open("/proc/self/status") as f:
    vsz = [int(l.split()[1]) * 1024 for l in f if l.startswith("VmSize:")][0]
resource.setrlimit(resource.RLIMIT_AS, (vsz + 400 * 1024 * 1024, hard))

base, nbad = rss(), 0
for i in range(65536):
    pat = (i << 16).to_bytes(4, "big")
    try:
        del ctx.translate((pat * (WINDOW // 4 + 1))[:WINDOW],
                          base_address=0x40000000 + i * 0x10000,
                          max_instructions=MAXI, max_bytes=WINDOW,
                          flags=pypcode.TranslateFlags.BB_TERMINATING)
    except MemoryError:
        nbad += 1
    except BaseException:
        pass
print("cum=%d nbad=%d" % (rss() - base, nbad))

On 559aacd this prints cum=419827712 nbad=13207 — the Context consumes the
entire 400 MB budget and then raises MemoryError('std::bad_alloc') on 13,207
of the remaining windows. It is stable across reruns and across two independent
builds; raising the cap to 900 MB just moves the numbers to 943,919,104 bytes
and 7,671. Retention is flat at about 6 MB through window 51,200 and then runs
away from 0xC8010000 onward.

Controls

  • SuperH4:BE:32:default 14.3 MB, 68000:BE:32:default 12.8 MB and
    Loongarch:LE:64:lp64d 6.8 MB all plateau over the same 65,536 windows with
    zero bad_alloc. Only pa-risc runs away.
  • Real PA-RISC code does not trigger it: 543,231 windows taken from compiled
    hppa binaries retain 7.9 MB with zero bad_alloc. Adversarial input is
    required.
  • Constructing a fresh Context every 128 windows gives zero bad_alloc with a
    worst transient of 2.85 MB, so the growth is retained in the Context and not
    in the returned translation.
  • A single bounded call is not the problem. Across roughly 1.6M windows the
    worst single translate under a 5000-byte bound was 21 MB (SuperH4:BE,
    77,500 ops), and work is linear in max_bytes.
  • Not the same defect as #289. With #289 applied the run gives
    cum=419868672 nbad=13208, i.e. unchanged.
  • Window size matters: at 400 bytes rather than 5000, the same sweep retains
    154,824,704 bytes and then stops growing, with zero bad_alloc under the same
    400 MB cap.

What I could not establish

The mechanism. Replaying only the tail windows (51,200-52,400) on a fresh
Context costs zero bytes, and three narrower probes — sampled hot-range
patterns, repeated hot patterns, and truncated history — showed no growth at
all and cannot be reconciled with the two deterministic full-sweep runs. So
"a long-lived pa-risc Context grows to whatever ceiling exists, on adversarial
input" is solid; anything about why is not, and I did not want to dress a guess
up as a diagnosis in a patch.

Why it matters

angr keeps one Context per architecture for the life of the process
(angr/engines/pcode/lifter.py), so retention here accumulates across an entire
CFG recovery. In practice angr clamps each block to 400 bytes, which is the
milder of the two regimes above, and real code does not trigger it — so this is
not currently causing the p-code out-of-memory aborts I was chasing, which have
a separate and well-understood cause. It is a sharp edge on untrusted input.

Measured on 559aacd, Linux x86-64, CPython 3.12.13.

主要语言
C++
星标
224
派生
33
平均合并
9 小时 30 分钟
30 天内合并 PR
14

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

angr/pypcode 的其他 Issue

查看 angr/pypcode 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。