morluto/rea

Fork 0

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

[GH-ISSUE #7350] [Bug] inspect_macho maps the selected ARM64 slice to a different same-named FAT row #4370

New issue

Closed

opened 2026-10-31 00:49:17 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:49:17 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 27, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7350

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

For an accepted universal Mach-O containing ARM64 V8 (subtype 1) before ARM64 ALL (subtype 0), Apple lipo prints both architecture names as arm64. REA runs otool -arch arm64, which reads ALL, but reports V8's container offset as the selected offset. The observed result also maps ALL's data segment into V8's bytes.

This was reproduced through production runProviderAnalysis and the native provider, including target admission, session routing, normalization, and Evidence registration. The runner invoked the real installed static native tools directly. The shell CLI/MCP transport and REA's native process supervisor were not executed; public CLI reachability was traced in source. No target code was run.

Reproduction

Use the stated baseline with its locked dependencies and existing built dist. The following script was executed on the stated host. It creates an inert FAT object containing two distinct, properly framed ARM64 object slices. Save it outside the checkout as reproduce.mjs:

import { mkdirSync, readFileSync, writeFileSync } from 'node:fs';
import { spawnSync } from 'node:child_process';
import { createHash } from 'node:crypto';
import { resolve, join } from 'node:path';
import { pathToFileURL } from 'node:url';
const [repo, work] = process.argv.slice(2).map(p => resolve(p));
const load = p => import(pathToFileURL(join(repo, 'dist', p)).href);
const { NativeMacOSProvider } = await load('native/NativeMacOSProvider.js');
const { composeBinarySession } = await load('application/binary/BinarySessionComposition.js');
const { AnalysisProviderRegistry } = await load('application/binary/AnalysisProviderRegistry.js');
const { runProviderAnalysis } = await load('application/DirectAnalysis.js');
mkdirSync(work, { recursive: true });
const thin = subtype => {
  const b = Buffer.alloc(4096);
  [0xfeedfacf, 0x0100000c, subtype, 1, 1, 152, 0, 0].forEach((v,i) => b.writeUInt32LE(v,i*4));
  b.writeUInt32LE(0x19,32); b.writeUInt32LE(152,36);
  b.writeBigUInt64LE(16n,64); b.writeBigUInt64LE(184n,72); b.writeBigUInt64LE(16n,80);
  b.writeUInt32LE(7,88); b.writeUInt32LE(7,92); b.writeUInt32LE(1,96);
  b.write('__data',104); b.write('__DATA',120); b.writeBigUInt64LE(16n,144);
  b.writeUInt32LE(184,152); b.writeUInt32LE(3,156); b.fill(0x41+subtype,184,200);
  return b;
};
const fat = Buffer.alloc(36864);
fat.writeUInt32BE(0xcafebabe); fat.writeUInt32BE(2,4);
for (const [i,sub,off] of [[0,1,16384],[1,0,32768]]) {
  [0x0100000c,sub,off,4096,14].forEach((v,j) => fat.writeUInt32BE(v,8+i*20+j*4));
  thin(sub).copy(fat,off);
}
const path = join(work,'fixture'); writeFileSync(path,fat);
const captures = [];
const runner = { run: async (tool,args) => {
  const executable = '/usr/bin/'+tool;
  const p = spawnSync(executable,args,{env:process.env,encoding:'utf8',timeout:15000,maxBuffer:1000000});
  if (p.error || p.status !== 0 || p.signal !== null) throw p.error ?? new Error(tool+': '+p.stdout+p.stderr);
  const c = {tool,executable,executableSha256:createHash('sha256').update(readFileSync(executable)).digest('hex'),
    toolVersion:null,versionReason:'No uniform version flag.',arguments:args,stdout:p.stdout,stderr:p.stderr,
    stdoutBytes:Buffer.byteLength(p.stdout),stderrBytes:Buffer.byteLength(p.stderr),exitCode:p.status,signal:p.signal};
  captures.push(c); return {ok:true,value:c};
}};
const result = await runProviderAnalysis({createNativeBinarySession: async () =>
  composeBinarySession(new AnalysisProviderRegistry([]),[new NativeMacOSProvider(process.env,runner)])},path,'inspect_macho',{});
writeFileSync(join(work,'captures.json'),JSON.stringify(captures,null,2));
writeFileSync(join(work,'evidence.json'),JSON.stringify(result,null,2));
console.log(JSON.stringify({selected:result.normalized_result?.selected_architecture,locations:result.locations,error:result.error}));

From the prepared checkout, run it with an owned scratch directory and isolated home/temp directories (replace REPRO_SCRIPT with the saved script's absolute path):

repo="$PWD"
work="$(mktemp -d)"
mkdir -p "$work/home" "$work/tmp"
HOME="$work/home" TMPDIR="$work/tmp" node "$REPRO_SCRIPT" "$repo" "$work"
otool -arch arm64 -h "$work/fixture"
otool -arch arm64v8 -h "$work/fixture"

The application reproduction returned selected offset 16384; the two otool commands printed subtypes 0 and 1, respectively. Every required native invocation exited 0 without a signal. A separate provider-boundary run returned the same wrong offset/range. For a shell CLI follow-up, the supported command is rea inspect-macho "$work/fixture" --format json; that full process invocation was not run in this verification.

The hunter's earlier header-only MH_EXECUTE fixture is not used here: actual dyld_info refuses it for a missing entrypoint, so it cannot establish successful inspection through all guards.

Expected behavior

selected_architecture.container_file_offset must identify the slice whose commands were inspected. Here -arch arm64 reads subtype 0 at 32768, so the selected base must be 32768 and its segment location must be [32952,32968). A typed refusal that explicitly preserves the ambiguity is preferable to a successful result with the wrong coordinates.

docs/native-investigation.md:533-548 promises exact selected-slice identity and container-relative Evidence locations derived from the selected base. src/domain/native/nativeInspection.ts:124-141 describes the selected offset as that slice's offset from the container start.

Impact and scope

A consumer that follows the returned segment Evidence range reads another slice's data: this fixture's selected ALL payload contains A bytes, while the returned range contains V8's B bytes. The source data and both architecture inventory ranges remain intact. The demonstrated scope is a V8-first/ALL-second FAT table accepted by target admission and all required native tools on this host; no shipped-binary prevalence or executable/entrypoint impact was established.

The failure depends on table order. Swapping only the two FAT-table rows restores correct selection metadata without changing slice bytes or physical offsets. A fresh lipo-created container places ALL first and also passes. Thinning the intended ALL slice with lipo -thin arm64 is a verified workaround: it produces bytes identical to the successfully inspected thin control, with selected offset zero. That copy has a different artifact identity, so retain original-container inventory separately.

REA version

6.8.0; source baseline dbe2c97af34361b11b9504e37611dd47715b52cb. Verification used the existing source-built runtime attributed to this baseline by its supplied build receipt; no build or installed-release check was performed.

Runtime and platform

Node.js v24.22.1; macOS 27.0.1, arm64. Real /usr/bin/lipo, otool, nm, dyld_info, dwarfdump, and vtool were used. NOT_ENOUGH_INFO for a uniform Apple-tool version: executable digests, command arguments, statuses, and complete outputs were retained locally instead. Hopper/Ghidra were not used.

Target and artifact context

A 36,864-byte FAT Mach-O with subtype-1 and subtype-0 CPU_TYPE_ARM64 slices at offsets 16384 and 32768, each 4096 bytes and aligned to 16384. Each slice is MH_OBJECT with one 152-byte LC_SEGMENT_64, one 16-byte __DATA/__data section at slice offset 184 and alignment 8, no symbols and no target execution. Slice CPU declarations agree with their embedded headers; production admission checked both load-command tables. This is a static object-inspection fixture, not a claim of a runnable executable.

Interface

CLI

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Fresh real lipo output and otool header reads:

lipo -detailed_info fixture:
  architecture arm64 / CPU_SUBTYPE_ARM64_V8 / offset 16384 / size 4096
  architecture arm64 / CPU_SUBTYPE_ARM64_ALL / offset 32768 / size 4096

otool -arch arm64 -h fixture:   cpusubtype 0, filetype 1, ncmds 1, sizeofcmds 152
otool -arch arm64v8 -h fixture: cpusubtype 1, filetype 1, ncmds 1, sizeofcmds 152

Executed shared CLI application result, projected to the relevant fields:

{
  "selected": { "name": "arm64", "container_file_offset": 16384 },
  "locations": [
    { "kind": "file-offset-range", "start": 16384, "end": 20480 },
    { "kind": "file-offset-range", "start": 32768, "end": 36864 },
    { "kind": "file-offset-range", "start": 16568, "end": 16584 }
  ]
}

The last location should be [32952,32968). The first two locations correctly inventory both slices and are not themselves the defect.

Independently executed provider control	Selected offset	Mapped segment range
V8 first / ALL second	16384 (wrong)	[16568,16584) (wrong)
Same bytes, only FAT-table row order swapped	32768	[32952,32968)
Thin ALL object	0	[184,200)
Fresh lipo-created FAT from the same objects, ALL first	48	[232,248)

All four provider runs succeeded, all native commands exited 0 without signals, and input digests remained unchanged. Real lipo -thin arm64 produced the same bytes as the passing thin control. The shared CLI application also successfully registered full Evidence with the wrong selected offset and range; this is not only a selection-helper test.

Typed outcome or recovery expected

Return the exact selected ALL row's container offset and correctly mapped Evidence locations, or refuse with an explicit typed ambiguous/unsupported selection. Preserve the two distinct architecture inventory records.

Analysis or suspected cause

Source-derived: src/native/MachoArchitectureSelection.ts:50-83 ranks the parsed subtype correctly but returns only architecture.name. src/native/NativeMachoInspection.ts:267-273 recovers the offset using the first row with that name. Both rows are named arm64, so the rank-winning ALL row loses its identity. The tool argument remains -arch arm64 (or --arch=arm64 for dwarfdump); fileOffsetLocations at lines 541-573 adds the incorrectly recovered base.

Additional context

Expected source: The documented exact selected-slice/container-location contract and output schema cited under Expected behavior.
Failure source: Fresh real native captures, successful production provider results, and registered Evidence from the shared CLI application reproduction above; the name-only offset lookup cited under Analysis explains the observed result.
Evidence provenance: observed. Public shell CLI/MCP reachability and the loss-of-row explanation are source-derived.
Local verification: reproduced at the native provider and shared CLI application boundaries with real static tools; only the subprocess runner was substituted. No build, installation, target execution, debugger, or live application operation was performed.
Reproduction completeness: complete for the stated application/provider contract violation. Full external CLI/MCP execution and production native supervision remain unverified; the missing observation is the same fixture through rea inspect-macho using the unmodified native command runner. The isolated runner avoids REA's ownership-helper compilation under the verification's no-build constraint.
Public reachability: src/cli/utilityCommands.ts:188-220 calls runProviderAnalysis; src/application/DirectAnalysis.ts selects the native-only session; src/composition/binary.ts:163-184 registers NativeMacOSProvider as an auxiliary provider. Actual session opening admitted this target on arm64, and the provider's timeout/format/required-command/output-schema guards all passed. src/server/registerNativeTools.ts exposes the same inspect_macho contract, but MCP was not run.
Restoration check: On the same V8-first input, require selected base 32768 and segment location [32952,32968), or an explicit typed ambiguity. Repeat the row-swapped and thin controls and preserve their correct coordinates and both FAT inventory rows. This is a proposed post-fix check; no fix was made.
Duplicate search: The saved complete issue history contains related closed coordinate/selection reports #1973, #812, and #2040. Those cover absent coordinate-base metadata, missing base addition, or unfiltered multi-slice commands. This baseline already implements those remedies, yet resolves the selected base to a different same-named row. Open #4280 concerns artifact inventory refusal, which is a separate contract. The complete saved history, final live issue and pull-request searches, related current discussions and recent reports contained no exact duplicate of this selected-row offset failure.
Distinct local case: Artifact slice-path collisions and extraction refusal have a separate closure signal. Repairing inventory paths can leave this successful inspection's selected coordinates wrong, and repairing selected-row identity can leave extraction paths colliding. This report makes no extraction claim.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: A supported, bounded FAT object layout returns successful Evidence whose selected base and mapped data range point into another slice. Real-world frequency and severe downstream consequences were not established.
Workaround status: available
Workaround basis: Real lipo thinning of ALL succeeded and produced bytes identical to the successfully inspected thin control; the workaround changes artifact identity, requiring original container inventory to be retained separately.

Originally created by @coygeek on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7350 ## Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ## Area Native analysis or decompilation ## Observed behavior For an accepted universal Mach-O containing ARM64 V8 (subtype 1) before ARM64 ALL (subtype 0), Apple lipo prints both architecture names as `arm64`. REA runs `otool -arch arm64`, which reads ALL, but reports V8's container offset as the selected offset. The observed result also maps ALL's data segment into V8's bytes. This was reproduced through production `runProviderAnalysis` and the native provider, including target admission, session routing, normalization, and Evidence registration. The runner invoked the real installed static native tools directly. The shell CLI/MCP transport and REA's native process supervisor were not executed; public CLI reachability was traced in source. No target code was run. ## Reproduction Use the stated baseline with its locked dependencies and existing built `dist`. The following script was executed on the stated host. It creates an inert FAT object containing two distinct, properly framed ARM64 object slices. Save it outside the checkout as `reproduce.mjs`: ```js import { mkdirSync, readFileSync, writeFileSync } from 'node:fs'; import { spawnSync } from 'node:child_process'; import { createHash } from 'node:crypto'; import { resolve, join } from 'node:path'; import { pathToFileURL } from 'node:url'; const [repo, work] = process.argv.slice(2).map(p => resolve(p)); const load = p => import(pathToFileURL(join(repo, 'dist', p)).href); const { NativeMacOSProvider } = await load('native/NativeMacOSProvider.js'); const { composeBinarySession } = await load('application/binary/BinarySessionComposition.js'); const { AnalysisProviderRegistry } = await load('application/binary/AnalysisProviderRegistry.js'); const { runProviderAnalysis } = await load('application/DirectAnalysis.js'); mkdirSync(work, { recursive: true }); const thin = subtype => { const b = Buffer.alloc(4096); [0xfeedfacf, 0x0100000c, subtype, 1, 1, 152, 0, 0].forEach((v,i) => b.writeUInt32LE(v,i*4)); b.writeUInt32LE(0x19,32); b.writeUInt32LE(152,36); b.writeBigUInt64LE(16n,64); b.writeBigUInt64LE(184n,72); b.writeBigUInt64LE(16n,80); b.writeUInt32LE(7,88); b.writeUInt32LE(7,92); b.writeUInt32LE(1,96); b.write('__data',104); b.write('__DATA',120); b.writeBigUInt64LE(16n,144); b.writeUInt32LE(184,152); b.writeUInt32LE(3,156); b.fill(0x41+subtype,184,200); return b; }; const fat = Buffer.alloc(36864); fat.writeUInt32BE(0xcafebabe); fat.writeUInt32BE(2,4); for (const [i,sub,off] of [[0,1,16384],[1,0,32768]]) { [0x0100000c,sub,off,4096,14].forEach((v,j) => fat.writeUInt32BE(v,8+i*20+j*4)); thin(sub).copy(fat,off); } const path = join(work,'fixture'); writeFileSync(path,fat); const captures = []; const runner = { run: async (tool,args) => { const executable = '/usr/bin/'+tool; const p = spawnSync(executable,args,{env:process.env,encoding:'utf8',timeout:15000,maxBuffer:1000000}); if (p.error || p.status !== 0 || p.signal !== null) throw p.error ?? new Error(tool+': '+p.stdout+p.stderr); const c = {tool,executable,executableSha256:createHash('sha256').update(readFileSync(executable)).digest('hex'), toolVersion:null,versionReason:'No uniform version flag.',arguments:args,stdout:p.stdout,stderr:p.stderr, stdoutBytes:Buffer.byteLength(p.stdout),stderrBytes:Buffer.byteLength(p.stderr),exitCode:p.status,signal:p.signal}; captures.push(c); return {ok:true,value:c}; }}; const result = await runProviderAnalysis({createNativeBinarySession: async () => composeBinarySession(new AnalysisProviderRegistry([]),[new NativeMacOSProvider(process.env,runner)])},path,'inspect_macho',{}); writeFileSync(join(work,'captures.json'),JSON.stringify(captures,null,2)); writeFileSync(join(work,'evidence.json'),JSON.stringify(result,null,2)); console.log(JSON.stringify({selected:result.normalized_result?.selected_architecture,locations:result.locations,error:result.error})); ``` From the prepared checkout, run it with an owned scratch directory and isolated home/temp directories (replace `REPRO_SCRIPT` with the saved script's absolute path): ```sh repo="$PWD" work="$(mktemp -d)" mkdir -p "$work/home" "$work/tmp" HOME="$work/home" TMPDIR="$work/tmp" node "$REPRO_SCRIPT" "$repo" "$work" otool -arch arm64 -h "$work/fixture" otool -arch arm64v8 -h "$work/fixture" ``` The application reproduction returned selected offset `16384`; the two otool commands printed subtypes `0` and `1`, respectively. Every required native invocation exited 0 without a signal. A separate provider-boundary run returned the same wrong offset/range. For a shell CLI follow-up, the supported command is `rea inspect-macho "$work/fixture" --format json`; that full process invocation was not run in this verification. The hunter's earlier header-only MH_EXECUTE fixture is not used here: actual dyld_info refuses it for a missing entrypoint, so it cannot establish successful inspection through all guards. ## Expected behavior `selected_architecture.container_file_offset` must identify the slice whose commands were inspected. Here `-arch arm64` reads subtype 0 at `32768`, so the selected base must be `32768` and its segment location must be `[32952,32968)`. A typed refusal that explicitly preserves the ambiguity is preferable to a successful result with the wrong coordinates. `docs/native-investigation.md:533-548` promises exact selected-slice identity and container-relative Evidence locations derived from the selected base. `src/domain/native/nativeInspection.ts:124-141` describes the selected offset as that slice's offset from the container start. ## Impact and scope A consumer that follows the returned segment Evidence range reads another slice's data: this fixture's selected ALL payload contains A bytes, while the returned range contains V8's B bytes. The source data and both architecture inventory ranges remain intact. The demonstrated scope is a V8-first/ALL-second FAT table accepted by target admission and all required native tools on this host; no shipped-binary prevalence or executable/entrypoint impact was established. The failure depends on table order. Swapping only the two FAT-table rows restores correct selection metadata without changing slice bytes or physical offsets. A fresh lipo-created container places ALL first and also passes. Thinning the intended ALL slice with `lipo -thin arm64` is a verified workaround: it produces bytes identical to the successfully inspected thin control, with selected offset zero. That copy has a different artifact identity, so retain original-container inventory separately. ## REA version 6.8.0; source baseline `dbe2c97af34361b11b9504e37611dd47715b52cb`. Verification used the existing source-built runtime attributed to this baseline by its supplied build receipt; no build or installed-release check was performed. ## Runtime and platform Node.js v24.22.1; macOS 27.0.1, arm64. Real `/usr/bin/lipo`, `otool`, `nm`, `dyld_info`, `dwarfdump`, and `vtool` were used. NOT_ENOUGH_INFO for a uniform Apple-tool version: executable digests, command arguments, statuses, and complete outputs were retained locally instead. Hopper/Ghidra were not used. ## Target and artifact context A 36,864-byte FAT Mach-O with subtype-1 and subtype-0 CPU_TYPE_ARM64 slices at offsets 16384 and 32768, each 4096 bytes and aligned to 16384. Each slice is MH_OBJECT with one 152-byte LC_SEGMENT_64, one 16-byte __DATA/__data section at slice offset 184 and alignment 8, no symbols and no target execution. Slice CPU declarations agree with their embedded headers; production admission checked both load-command tables. This is a static object-inspection fixture, not a claim of a runnable executable. ## Interface CLI ## Earliest failure stage Native analysis or reconstruction ## Relevant output or evidence Fresh real lipo output and otool header reads: ```text lipo -detailed_info fixture: architecture arm64 / CPU_SUBTYPE_ARM64_V8 / offset 16384 / size 4096 architecture arm64 / CPU_SUBTYPE_ARM64_ALL / offset 32768 / size 4096 otool -arch arm64 -h fixture: cpusubtype 0, filetype 1, ncmds 1, sizeofcmds 152 otool -arch arm64v8 -h fixture: cpusubtype 1, filetype 1, ncmds 1, sizeofcmds 152 ``` Executed shared CLI application result, projected to the relevant fields: ```json { "selected": { "name": "arm64", "container_file_offset": 16384 }, "locations": [ { "kind": "file-offset-range", "start": 16384, "end": 20480 }, { "kind": "file-offset-range", "start": 32768, "end": 36864 }, { "kind": "file-offset-range", "start": 16568, "end": 16584 } ] } ``` The last location should be `[32952,32968)`. The first two locations correctly inventory both slices and are not themselves the defect. | Independently executed provider control | Selected offset | Mapped segment range | | --- | ---: | --- | | V8 first / ALL second | 16384 (wrong) | [16568,16584) (wrong) | | Same bytes, only FAT-table row order swapped | 32768 | [32952,32968) | | Thin ALL object | 0 | [184,200) | | Fresh lipo-created FAT from the same objects, ALL first | 48 | [232,248) | All four provider runs succeeded, all native commands exited 0 without signals, and input digests remained unchanged. Real `lipo -thin arm64` produced the same bytes as the passing thin control. The shared CLI application also successfully registered full Evidence with the wrong selected offset and range; this is not only a selection-helper test. ## Typed outcome or recovery expected Return the exact selected ALL row's container offset and correctly mapped Evidence locations, or refuse with an explicit typed ambiguous/unsupported selection. Preserve the two distinct architecture inventory records. ## Analysis or suspected cause Source-derived: `src/native/MachoArchitectureSelection.ts:50-83` ranks the parsed subtype correctly but returns only `architecture.name`. `src/native/NativeMachoInspection.ts:267-273` recovers the offset using the first row with that name. Both rows are named `arm64`, so the rank-winning ALL row loses its identity. The tool argument remains `-arch arm64` (or `--arch=arm64` for dwarfdump); `fileOffsetLocations` at lines 541-573 adds the incorrectly recovered base. ## Additional context - Expected source: The documented exact selected-slice/container-location contract and output schema cited under Expected behavior. - Failure source: Fresh real native captures, successful production provider results, and registered Evidence from the shared CLI application reproduction above; the name-only offset lookup cited under Analysis explains the observed result. - Evidence provenance: observed. Public shell CLI/MCP reachability and the loss-of-row explanation are source-derived. - Local verification: reproduced at the native provider and shared CLI application boundaries with real static tools; only the subprocess runner was substituted. No build, installation, target execution, debugger, or live application operation was performed. - Reproduction completeness: complete for the stated application/provider contract violation. Full external CLI/MCP execution and production native supervision remain unverified; the missing observation is the same fixture through `rea inspect-macho` using the unmodified native command runner. The isolated runner avoids REA's ownership-helper compilation under the verification's no-build constraint. - Public reachability: `src/cli/utilityCommands.ts:188-220` calls `runProviderAnalysis`; `src/application/DirectAnalysis.ts` selects the native-only session; `src/composition/binary.ts:163-184` registers NativeMacOSProvider as an auxiliary provider. Actual session opening admitted this target on arm64, and the provider's timeout/format/required-command/output-schema guards all passed. `src/server/registerNativeTools.ts` exposes the same inspect_macho contract, but MCP was not run. - Restoration check: On the same V8-first input, require selected base 32768 and segment location [32952,32968), or an explicit typed ambiguity. Repeat the row-swapped and thin controls and preserve their correct coordinates and both FAT inventory rows. This is a proposed post-fix check; no fix was made. - Duplicate search: The saved complete issue history contains related closed coordinate/selection reports [#1973](https://github.com/morluto/rea/issues/1973), [#812](https://github.com/morluto/rea/pull/812), and [#2040](https://github.com/morluto/rea/pull/2040). Those cover absent coordinate-base metadata, missing base addition, or unfiltered multi-slice commands. This baseline already implements those remedies, yet resolves the selected base to a different same-named row. Open [#4280](https://github.com/morluto/rea/issues/4280) concerns artifact inventory refusal, which is a separate contract. The complete saved history, final live issue and pull-request searches, related current discussions and recent reports contained no exact duplicate of this selected-row offset failure. - Distinct local case: Artifact slice-path collisions and extraction refusal have a separate closure signal. Repairing inventory paths can leave this successful inspection's selected coordinates wrong, and repairing selected-row identity can leave extraction paths colliding. This report makes no extraction claim. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: A supported, bounded FAT object layout returns successful Evidence whose selected base and mapped data range point into another slice. Real-world frequency and severe downstream consequences were not established. - Workaround status: available - Workaround basis: Real lipo thinning of ALL succeeded and produced bytes identical to the successfully inspected thin control; the workaround changes artifact identity, requiring original container inventory to be retained separately.

bsakaguchi closed this issue

2026-10-31 00:49:17 +00:00

bsakaguchi referenced this issue

2026-10-31 01:12:51 +00:00

[PR #4416] [MERGED] fix(dotnet): reject unfinished CIL prefix chains #6227

bsakaguchi referenced this issue

2026-10-31 01:13:19 +00:00

[PR #4528] [CLOSED] fix(dotnet): reject unfinished CIL prefix chain at end of method body #6288