morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #5930] [Bug] batch_decompile accepts unbounded address arrays #3605

New issue

Open

opened 2026-10-31 00:42:19 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:42:19 +00:00

Owner

Originally created by @dakjdakd on GitHub (Oct 21, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5930

Summary

The batch_decompile operation accepts an arbitrary number of procedure addresses in one request. Because the same input is exposed through the CLI, MCP, and direct application dispatch, an oversized request can expand into a very large provider workload and response before the caller receives a useful validation error.

Background

batch_decompile is designed for bounded batches of provider-normalized addresses. The repository already defines MAX_ENHANCED_RECORDS as the shared upper bound for enhanced analysis records, and the other enhanced operations use that bound when their contracts accept collections.

Problem

The batch_decompile address schema currently validates element types but does not apply the shared record limit. The runtime therefore accepts a request whose size is far beyond the intended enhanced-analysis budget. The request can pass through the common dispatch path and reach provider work before the caller gets a structured input error.

Expected behavior

The canonical batch_decompile contract should reject any address array larger than MAX_ENHANCED_RECORDS. The same limit and error shape should be visible through every supported entry point, and invalid input should be rejected before any provider call is made.

Scope

This issue is limited to the input contract and its validation boundary. It does not change the behavior or output format of legal batches, provider scheduling, or result pagination.

Originally created by @dakjdakd on GitHub (Oct 21, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5930 ## Summary The `batch_decompile` operation accepts an arbitrary number of procedure addresses in one request. Because the same input is exposed through the CLI, MCP, and direct application dispatch, an oversized request can expand into a very large provider workload and response before the caller receives a useful validation error. ## Background `batch_decompile` is designed for bounded batches of provider-normalized addresses. The repository already defines `MAX_ENHANCED_RECORDS` as the shared upper bound for enhanced analysis records, and the other enhanced operations use that bound when their contracts accept collections. ## Problem The `batch_decompile` address schema currently validates element types but does not apply the shared record limit. The runtime therefore accepts a request whose size is far beyond the intended enhanced-analysis budget. The request can pass through the common dispatch path and reach provider work before the caller gets a structured input error. ## Expected behavior The canonical `batch_decompile` contract should reject any address array larger than `MAX_ENHANCED_RECORDS`. The same limit and error shape should be visible through every supported entry point, and invalid input should be rejected before any provider call is made. ## Scope This issue is limited to the input contract and its validation boundary. It does not change the behavior or output format of legal batches, provider scheduling, or result pagination.

bsakaguchi commented

2026-10-31 00:42:20 +00:00

Author

Owner

@dakjdakd commented on GitHub (Oct 21, 2026):

The focused implementation is ready on dakjdakd/rea:fix/batch-decompile-input-budget at commit 729d648b2a. The corresponding draft PR body is prepared and will be submitted as soon as pull-request creation is available for this account.

@dakjdakd commented on GitHub (Oct 21, 2026): The focused implementation is ready on dakjdakd/rea:fix/batch-decompile-input-budget at commit 729d648b2a842ac8cd503d6b43412bea9cc482d5. The corresponding draft PR body is prepared and will be submitted as soon as pull-request creation is available for this account.

bsakaguchi referenced this issue

2026-10-31 01:09:42 +00:00

[PR #3559] [CLOSED] fix(electron): block and record shell.trashItem #5823

bsakaguchi referenced this issue

2026-10-31 01:09:55 +00:00

[PR #3605] [MERGED] fix(electron): reject active scenario capture when inspect fuse is disabled (#3453) #5852

bsakaguchi commented

2026-11-01 21:11:01 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Current public surface and design scope

On REA b43c329df779708e43ae297f498a844e45d9c923, the actual stdio MCP tools/list input schema still accepts an array of strings with no item-count bound. The tool description explicitly advises small batches and says the complete reply retains all pseudocode. A real Ghidra 12.1.4 and Kuna 1.986 MCP control with four mixed function selectors retained the input order and returned the correct aggregate counts, including successful results and a per-item ambiguity. This is a small correctness control, not an oversized workload or resource measurement.

Two details in the original issue need rechecking against the current surface: the repository's native-investigation guide says batch_decompile has no dedicated CLI command, and running rea batch-decompile --format json returned COMMAND_NOT_FOUND. Source search on this revision found no MAX_ENHANCED_RECORDS definition. This does not remove the underlying resource-bound question, and does not rule out other direct application consumers.

The current guide explicitly says the MCP response budget is checked after provider work and retained batch state, and that the general admission/output policy remains unresolved. Please evaluate a bound against actual provider work and retained pseudocode/serialization expansion, partial-result and Evidence behavior, and client recovery rather than assume the historical constant or a count alone is sufficient. Distinguish missing from explicitly empty selection (#8181). No new arbitrary limit or empirical model failure is established by this comment.

@morluto commented on GitHub (Oct 31, 2026): ### Current public surface and design scope On REA `b43c329df779708e43ae297f498a844e45d9c923`, the actual stdio MCP `tools/list` input schema still accepts an array of strings with no item-count bound. The tool description explicitly advises small batches and says the complete reply retains all pseudocode. A real Ghidra 12.1.4 and Kuna 1.986 MCP control with four mixed function selectors retained the input order and returned the correct aggregate counts, including successful results and a per-item ambiguity. This is a small correctness control, **not** an oversized workload or resource measurement. Two details in the original issue need rechecking against the current surface: the repository's native-investigation guide says `batch_decompile` has no dedicated CLI command, and running `rea batch-decompile --format json` returned `COMMAND_NOT_FOUND`. Source search on this revision found no `MAX_ENHANCED_RECORDS` definition. This does not remove the underlying resource-bound question, and does not rule out other direct application consumers. The current guide explicitly says the MCP response budget is checked after provider work and retained batch state, and that the general admission/output policy remains unresolved. Please evaluate a bound against actual provider work **and** retained pseudocode/serialization expansion, partial-result and Evidence behavior, and client recovery rather than assume the historical constant or a count alone is sufficient. Distinguish missing from explicitly empty selection (#8181). No new arbitrary limit or empirical model failure is established by this comment.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3605

No description provided.

Rows
Columns