Harden dumpDebugLoc against malformed .debug_loc sections
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Start in dumpDebugLoc in third_party/llvm-project/dwarf2yaml.cpp, where the exit(1) on a null list sits, and read parseOneLocationList to see how entry.Loc is sized before the copy. Check how the address size is taken from the first CU. Done means a malformed list prints a warning and skips the rest of the section instead of exiting, the entry.Loc length is bounded, and a debug-build assert covers the shared address size. The issue does not give the length limit, so that needs a maintainer decision.
索引モデルが issue の本文から書いたものです。
説明
Background:
#6879 was a SIGSEGV in dumpDebugLoc for modules with empty .debug_loc
sections. Fixed by #7910 with a null-CU guard. While reviewing that fix,
three defensive improvements to the same function became apparent. None
is a regression, but each turns a malformed-input case into a hard
failure when it could fail gracefully.
Location: third_party/llvm-project/dwarf2yaml.cpp, dumpDebugLoc.
-
exit(1)on parse failure.if (!list) { errs() << "debug_loc error\n"; exit(1); }A single malformed location list aborts the entire
wasm-optrun. A
warning plus break (skip the rest of the section) would let the tool
finish processing the module with incomplete debug info, which is
the behavior for every other diagnostic in wasm-opt. -
Unbounded copy of location expression bytes.
entry.Locis read from the section byparseOneLocationList. There is
no upper bound on its length before the copy intoloc.Location. A
malformed length field causes unbounded allocation. -
Address-size heuristic.
The comment "should be ok since they all have the same address size?"
is a heuristic. All CUs in well-formed modules share the same
AddrSize, so reading it from the first CU is safe in practice, but
the assumption is not enforced.
Proposed changes:
- Replace
exit(1)with a warning and break. - Add a length sanity check before copying
entry.Loc. - Promote the
address-sizecomment from a question to an explicit
assumption with a debug-build assert.
Refs #6879, #7910.
- 主要言語
- WebAssembly
- スター
- 8.7k
- フォーク
- 895
- 平均マージ
- 1日 22時間
- マージ済み PR（30日）
- 97
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
WebAssembly/binaryen のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
WebAssembly/binaryen#9135 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 半日 初心者へのやさしさ 76/100
WebAssembly/binaryen#9018 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
WebAssembly/binaryen#9246 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Memory64Lowering: table.get/table.set keep i64 index on lowered table64, output fails validationオープン
難易度 3/5 半日 初心者へのやさしさ 66/100
WebAssembly/binaryen#9245 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
WebAssembly/binaryen#9244 ·
メンテナーはふだん 1 日以内に返信
WebAssembly/binaryen の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
parcel-bundler/lightningcss#1370 ·
メンテナーはふだん 1 日以内に返信
-
bug intrinsic low priority rt_lib
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
flang:semantics
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
llvm/llvm-project#231051 ·
メンテナーはふだん 1 日以内に返信
-
Bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100