[GH-ISSUE #5876] [Bug] Binwalk inspection can exit zero without producing its requested report #3561

New issue

Closed

opened 2026-10-31 00:41:52 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:41:52 +00:00

Owner

Originally created by @gensokyo-dev on GitHub (Oct 21, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5876

Originally assigned to: @kaoru0822-kitauji on GitHub.

Before submitting / area

Searched open and closed Binwalk/report issues; #3758 concerns doctor coverage and #3888 extraction/report size, not this intermittent inspection outcome.
No credentials, sensitive target data or private installation paths included.

Area: Provider or capability discovery / CLI.

Observed behavior

Real Binwalk 3.1.0 occasionally exits 0 with empty stdout/stderr but does not create the requested --log report.json. REA returns unreadable_output with generic rea doctor guidance. This is an observed intermittent result, not a source-only hypothesis.

It reproduces on baseline f801b2fbfd, before firmware timeout PR #5863. Do not attribute it to the new adjustable analysis timer.

Reproduction actually run

Generate the repository's independent Python USTAR/gzip/compiled-ELF fixture with REA_FIRMWARE_FIXTURE_ROOT=<scratch> npm run fixtures:firmware; configure an absolute caller-supplied Binwalk 3.1.0 executable. Run:

node scripts/rea.mjs inspect-firmware-regions <scratch>/firmware.bin --json

A follow-up production-boundary trace used createFirmwareAnalysisProvider, the real spawnOwnedProviderProcess, the unchanged real Binwalk/prlimit command and existing ownership cleanup. The launcher hook only inspected the report path immediately before and after cleanup; it did not emulate the producer or change command arguments/limits. In that traced run, baseline failed 2/12 inspections; current default/max-budget controls succeeded 24/24. An earlier separate CLI control run was baseline 6/6 successes and current max-budget 5/6 successes. These are small, timing-sensitive samples, not reliable failure-rate estimates or a regression comparison.

Expected behavior / recovery

Keep the missing report explicit: an exit status of 0 is not empty/complete scan Evidence. Preserve relevant command/exit/report facts and give inspection-specific next checks instead of presenting generic doctor advice as a demonstrated repair. No unchanged automatic retry or fabricated successful scan is proposed.

Impact and scope

The tiny, otherwise supported fixture can fail after apparently successful analysis. No source mutation or false successful Evidence was observed. Vendor firmware, larger images, other Binwalk builds/platforms and the causal repair are NOT_ENOUGH_INFO; they were not tested.

Version / runtime / target / interface / earliest stage

REA baseline: f801b2fbfd.
Node 24.18.0; Linux x64; Binwalk 3.1.0 built from the locked official crate; util-linux prlimit.
Binwalk executable SHA-256: 60bbb541f75f8d59db4ab4c52915e29200eba3b4b96e08d89f97722423c595e3.
Generated firmware: 2859 bytes, SHA-256 790bfe9467e0d08cee4d41ea8e25141809be3227d415cb01ff67dba7e16e43b1; gzip offset 64, length 2667. No extracted-code execution.
Interface: observed CLI and real production boundary; earlier public MCP check also observed missing report.
Earliest observed stage: producer completion / report consumption. Causal stage remains unknown.

Smallest relevant observed evidence

For both failed baseline traced scans:

{"leader_exit_code_before_cleanup":0,"report_before_cleanup":"ENOENT","cleanup":{"cleaned":true,"signaled":false},"report_after_cleanup":"ENOENT"}

Invocation: prlimit --as=1073741824 --fsize=8388608 --core=0 --cpu=120 -- <binwalk> --quiet --search-all --threads 1 --log <owned-workspace>/report.json <owned-workspace>/firmware.bin.

Observed reader cause: ENOENT: no such file or directory, open '<owned-workspace>/report.json'; REA AnalysisOutputError projection: unreadable_output, retryable false, reason Tool did not produce the expected complete report … stdout (0 bytes) … stderr (0 bytes).

Analysis / unknowns

The report was already absent before REA's verified, non-signaling cleanup; that particular observation is not a report lost during workspace removal or a leader killed by that cleanup. Root cause is NOT_ENOUGH_INFO. It is not established whether Binwalk, resource policy, environment/filesystem behavior or another boundary causes it. Proposed next checks (not executed): trace actual report creation/open failures in the real producer and compare direct pinned Binwalk invocations with the same constraints. Do not weaken resource limits or report validation without causal evidence.

Originally created by @gensokyo-dev on GitHub (Oct 21, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5876 Originally assigned to: @kaoru0822-kitauji on GitHub. ### Before submitting / area - [x] Searched open and closed Binwalk/report issues; #3758 concerns doctor coverage and #3888 extraction/report size, not this intermittent inspection outcome. - [x] No credentials, sensitive target data or private installation paths included. Area: Provider or capability discovery / CLI. ### Observed behavior Real Binwalk 3.1.0 occasionally exits 0 with empty stdout/stderr but does not create the requested `--log report.json`. REA returns `unreadable_output` with generic `rea doctor` guidance. This is an observed intermittent result, not a source-only hypothesis. It reproduces on baseline **f801b2fbfd28f4e3713adefddc7bd73db44c284c**, before firmware timeout PR #5863. Do not attribute it to the new adjustable analysis timer. ### Reproduction actually run Generate the repository's independent Python USTAR/gzip/compiled-ELF fixture with `REA_FIRMWARE_FIXTURE_ROOT=<scratch> npm run fixtures:firmware`; configure an absolute caller-supplied Binwalk 3.1.0 executable. Run: ```sh node scripts/rea.mjs inspect-firmware-regions <scratch>/firmware.bin --json ``` A follow-up production-boundary trace used `createFirmwareAnalysisProvider`, the real `spawnOwnedProviderProcess`, the unchanged real Binwalk/prlimit command and existing ownership cleanup. The launcher hook only inspected the report path immediately before and after cleanup; it did not emulate the producer or change command arguments/limits. In that traced run, baseline failed **2/12** inspections; current default/max-budget controls succeeded **24/24**. An earlier separate CLI control run was baseline 6/6 successes and current max-budget 5/6 successes. These are small, timing-sensitive samples, not reliable failure-rate estimates or a regression comparison. ### Expected behavior / recovery Keep the missing report explicit: an exit status of 0 is not empty/complete scan Evidence. Preserve relevant command/exit/report facts and give inspection-specific next checks instead of presenting generic doctor advice as a demonstrated repair. No unchanged automatic retry or fabricated successful scan is proposed. ### Impact and scope The tiny, otherwise supported fixture can fail after apparently successful analysis. No source mutation or false successful Evidence was observed. Vendor firmware, larger images, other Binwalk builds/platforms and the causal repair are **NOT_ENOUGH_INFO**; they were not tested. ### Version / runtime / target / interface / earliest stage - REA baseline: f801b2fbfd28f4e3713adefddc7bd73db44c284c. - Node 24.18.0; Linux x64; Binwalk 3.1.0 built from the locked official crate; util-linux prlimit. - Binwalk executable SHA-256: `60bbb541f75f8d59db4ab4c52915e29200eba3b4b96e08d89f97722423c595e3`. - Generated firmware: 2859 bytes, SHA-256 `790bfe9467e0d08cee4d41ea8e25141809be3227d415cb01ff67dba7e16e43b1`; gzip offset 64, length 2667. No extracted-code execution. - Interface: observed CLI and real production boundary; earlier public MCP check also observed missing report. - Earliest observed stage: producer completion / report consumption. Causal stage remains unknown. ### Smallest relevant observed evidence For both failed baseline traced scans: ```json {"leader_exit_code_before_cleanup":0,"report_before_cleanup":"ENOENT","cleanup":{"cleaned":true,"signaled":false},"report_after_cleanup":"ENOENT"} ``` Invocation: `prlimit --as=1073741824 --fsize=8388608 --core=0 --cpu=120 -- <binwalk> --quiet --search-all --threads 1 --log <owned-workspace>/report.json <owned-workspace>/firmware.bin`. Observed reader cause: `ENOENT: no such file or directory, open '<owned-workspace>/report.json'`; REA `AnalysisOutputError` projection: `unreadable_output`, retryable false, reason `Tool did not produce the expected complete report … stdout (0 bytes) … stderr (0 bytes)`. ### Analysis / unknowns The report was already absent before REA's verified, non-signaling cleanup; that particular observation is not a report lost during workspace removal or a leader killed by that cleanup. Root cause is **NOT_ENOUGH_INFO**. It is not established whether Binwalk, resource policy, environment/filesystem behavior or another boundary causes it. Proposed next checks (not executed): trace actual report creation/open failures in the real producer and compare direct pinned Binwalk invocations with the same constraints. Do not weaken resource limits or report validation without causal evidence.

bsakaguchi

2026-10-31 00:41:52 +00:00