[GH-ISSUE #6737] [Bug] High-bit CCOB signature corruption is accepted as a valid HIP bundle #4100

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Before submitting

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

Duplicate checking covered the supplied open snapshot plus repository searches across open and closed reports for CCOB, high-bit, and signature ASCII. No matching CCOB signature report was found.

Area

Native analysis or decompilation

Observed behavior

The production source service accepts a CCOB v3 container after changing only its first byte from 0x43 to 0xC3. The bytes c3 43 4f 42 are not the 43 43 4f 42 CCOB signature, but inspection identifies hip-bundle, returns kernel add_one, and reports complete discovery and payload coverage without an object limitation. The same corrupted container inside an ELF .hip_fatbin section also returns complete coverage. Changing the first byte to ASCII D instead correctly refuses standalone recognition.

Reproduction

With the source revision below and its existing locked dependencies, save the executed probe below as /tmp/rea-gpu-fixtures/ccob-magic.mts. REPO names that prepared checkout. The fixtures contain inert AMDGPU metadata; the probe executes no target code.

mkdir -p /tmp/rea-gpu-fixtures
node --import "$REPO/node_modules/tsx/dist/loader.mjs" \
  /tmp/rea-gpu-fixtures/ccob-magic.mts "$REPO" /tmp/rea-gpu-fixtures

import {writeFile} from 'node:fs/promises';
import {join,resolve} from 'node:path';
import {pathToFileURL} from 'node:url';
const [repoArg,workArg]=process.argv.slice(2),repo=resolve(repoArg),work=resolve(workArg);
const load=(p:string)=>import(pathToFileURL(join(repo,p)).href);
const {GpuCodeObjectsService}=await load('src/application/gpu/GpuCodeObjectsService.ts');
const {GpuCodeObjectsProvider}=await load('src/gpu/GpuCodeObjectsProvider.ts');
const {ccobFixture,elfFixture,cubinFixture}=await load('tests/fixtures/gpu/codeObjects.ts');
const clean=ccobFixture(3,'zlib');
const high=Buffer.from(clean);high[0]|=0x80;
const wrong=Buffer.from(clean);wrong[0]=0x44;
console.log(JSON.stringify({node:process.version,platform:process.platform,arch:process.arch}));
for(const [name,bytes] of [['ccob-clean',clean],['ccob-high-bit',high],['ccob-wrong',wrong],['elf-high-bit',elfFixture(62,[{name:'.hip_fatbin',bytes:high}])]] as const){
 const path=join(work,name+'.bin');await writeFile(path,bytes);
 const service=new GpuCodeObjectsService(new GpuCodeObjectsProvider());
 try {
  const result=await service.inspect({path,analysis:'kernels',detail:'complete'});
  await writeFile(join(work,name+'.result.json'),JSON.stringify(result,null,2));
  const r=result.ok?result.value.normalized_result:null;
  console.log(JSON.stringify({case:name,magic:bytes.subarray(0,4).toString('hex'),ascii:bytes.subarray(0,4).toString('ascii'),ok:result.ok,error:result.ok?undefined:{tag:result.error._tag,message:result.error.message},format:r?.format,coverage:r?.coverage,kernels:r?.kernels.map(k=>k.name),objects:r?.objects.map(o=>({kind:o.kind,inspection:o.inspection,limitations:o.limitations}))}));
 }finally{await service.close();}
}

Executed once, with one service request for each of the four cases. The process exited successfully. A separate direct byte comparison confirmed that the clean sample starts with CCOB and the high-bit sample does not.

Expected behavior

Require the exact binary CCOB signature before interpreting its header and reporting complete CCOB discovery. Reject or explicitly mark the corrupted signature unsupported/malformed rather than silently accepting it as a valid container. The repository's CCOB fixture producer writes the literal signature, and the recognition branch explicitly identifies this spelling.

Impact and scope

A damaged container header is silently normalized into a recognized, completely inspected GPU artifact. This creates incorrect format/completeness evidence for these bounded inputs. Both standalone CCOB and an ELF-embedded CCOB were observed. Valid fixtures still decode normally; no file mutation, crash, GPU execution, or security impact was observed. Frequency in real artifacts and other signature-bit combinations were not measured. Callers can check the first four container bytes for exact equality before inspection; the retained fixtures directly distinguish the clean and corrupted signatures.

REA version

Main source bc411c24befceced5a9ea1ca1c1ce123fd02bf48, package metadata 6.7.0, was executed through the source service. Separately, the installed published rea-agents package also reports metadata version 6.7.0, but its CLI returned COMMAND_NOT_FOUND for inspect-gpu-code-objects. This is a main-source finding; published-release parser behavior was not established.

Runtime and platform

Node.js v24.22.1; Linux 7.2.8-9-omarchy x86_64; repository-locked tsx loader. No GPU toolkit or external analysis provider.

Target and artifact context

Synthetic CCOB v3 zlib container around a Clang HIP bundle with one AMDGPU MessagePack kernel declaration; also wrapped in a synthetic ELF64 x86_64 .hip_fatbin section. The negative control changes the first byte to ASCII D; all payload, length and digest bytes remain unchanged between the standalone signature cases. These are format fixtures, not complete executable GPU programs.

Interface

Other — production GpuCodeObjectsService.inspect. Main CLI and MCP transports were not executed; the published CLI command-discovery attempt is reported separately above.

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Selected fields from the observed service output:

case              first bytes   ok     format       discovery  payloads  kernels
ccob-clean        43434f42      true   hip-bundle   complete   complete  add_one
ccob-high-bit     c3434f42      true   hip-bundle   complete   complete  add_one
ccob-wrong        44434f42      false  AnalysisUnsupportedTargetError
elf-high-bit      7f454c46      true   elf          complete   complete  add_one

Every object in both accepted high-bit cases had inspection: "complete" and an empty limitations array. In the ELF case, the corrupted CCOB signature is inside .hip_fatbin, rather than at the root ELF signature.

Expected source: exact signature written by the fixture producer and intended comparison in the recognition branch linked above.
Failure source: executed production source-service probe and output above.
Evidence provenance: observed.
Local verification: reproduced.
Reproduction completeness: complete for the synthetic service cases.

Typed outcome or recovery expected

Return an unsupported/malformed signature outcome for the standalone corrupted CCOB, and preserve an explicit incomplete/refused embedded payload for the ELF case. Keep the unmodified container successful.

Analysis or suspected cause

Source-derived: both standalone recognition and the HIP container loop compare Buffer.toString("ascii") with "CCOB". The observed probe prints ascii: "CCOB" for c3434f42: that decoder strips the high bit. The header reader then validates lengths and versions without rechecking the signature bytes. Comparing the original bytes at the owning signature boundary would avoid this lossy interpretation.

Additional context

Compared against the supplied open-issue snapshot and focused open/closed repository searches. #6703 concerns CCOB v1 consuming later aligned bundles; this report uses a single v3 container and an invalid magic byte. #6719 and #6704 concern HIP target spellings; #6718 concerns a legacy CUDA compression flag. None describes this exact-byte signature recognition failure. Closed #2343 reports the same lossy ASCII-decoding pattern in src/domain/dosMz.ts for Windows signatures; this finding is in the separate CCOB reader and GPU workflow, and does not duplicate that Windows-header behavior. PTX parsing, GGUF and Safetensors were excluded. Real compiler-produced damaged artifacts, other CCOB versions/codecs, other platforms, and first affected revision are NOT_ENOUGH_INFO. Prepared with AI assistance.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: The observed source service turns an invalid container signature into successful recognized GPU evidence with complete coverage in two container contexts, without changing the input.
Workaround status: available
Workaround basis: An exact four-byte signature comparison distinguishes the retained clean and corrupted samples before inspection; valid CCOB bytes remain accepted. Callers must locate embedded container ranges to apply this check there.

Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6737 ## 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. Duplicate checking covered the supplied open snapshot plus repository searches across open and closed reports for `CCOB`, `high-bit`, and `signature ASCII`. No matching CCOB signature report was found. ## Area Native analysis or decompilation ## Observed behavior The production source service accepts a CCOB v3 container after changing only its first byte from `0x43` to `0xC3`. The bytes `c3 43 4f 42` are not the `43 43 4f 42` CCOB signature, but inspection identifies `hip-bundle`, returns kernel `add_one`, and reports complete discovery and payload coverage without an object limitation. The same corrupted container inside an ELF `.hip_fatbin` section also returns complete coverage. Changing the first byte to ASCII `D` instead correctly refuses standalone recognition. ## Reproduction With the source revision below and its existing locked dependencies, save the executed probe below as `/tmp/rea-gpu-fixtures/ccob-magic.mts`. `REPO` names that prepared checkout. The fixtures contain inert AMDGPU metadata; the probe executes no target code. ```sh mkdir -p /tmp/rea-gpu-fixtures node --import "$REPO/node_modules/tsx/dist/loader.mjs" \ /tmp/rea-gpu-fixtures/ccob-magic.mts "$REPO" /tmp/rea-gpu-fixtures ``` ```ts import {writeFile} from 'node:fs/promises'; import {join,resolve} from 'node:path'; import {pathToFileURL} from 'node:url'; const [repoArg,workArg]=process.argv.slice(2),repo=resolve(repoArg),work=resolve(workArg); const load=(p:string)=>import(pathToFileURL(join(repo,p)).href); const {GpuCodeObjectsService}=await load('src/application/gpu/GpuCodeObjectsService.ts'); const {GpuCodeObjectsProvider}=await load('src/gpu/GpuCodeObjectsProvider.ts'); const {ccobFixture,elfFixture,cubinFixture}=await load('tests/fixtures/gpu/codeObjects.ts'); const clean=ccobFixture(3,'zlib'); const high=Buffer.from(clean);high[0]|=0x80; const wrong=Buffer.from(clean);wrong[0]=0x44; console.log(JSON.stringify({node:process.version,platform:process.platform,arch:process.arch})); for(const [name,bytes] of [['ccob-clean',clean],['ccob-high-bit',high],['ccob-wrong',wrong],['elf-high-bit',elfFixture(62,[{name:'.hip_fatbin',bytes:high}])]] as const){ const path=join(work,name+'.bin');await writeFile(path,bytes); const service=new GpuCodeObjectsService(new GpuCodeObjectsProvider()); try { const result=await service.inspect({path,analysis:'kernels',detail:'complete'}); await writeFile(join(work,name+'.result.json'),JSON.stringify(result,null,2)); const r=result.ok?result.value.normalized_result:null; console.log(JSON.stringify({case:name,magic:bytes.subarray(0,4).toString('hex'),ascii:bytes.subarray(0,4).toString('ascii'),ok:result.ok,error:result.ok?undefined:{tag:result.error._tag,message:result.error.message},format:r?.format,coverage:r?.coverage,kernels:r?.kernels.map(k=>k.name),objects:r?.objects.map(o=>({kind:o.kind,inspection:o.inspection,limitations:o.limitations}))})); }finally{await service.close();} } ``` Executed once, with one service request for each of the four cases. The process exited successfully. A separate direct byte comparison confirmed that the clean sample starts with `CCOB` and the high-bit sample does not. ## Expected behavior Require the exact binary CCOB signature before interpreting its header and reporting complete CCOB discovery. Reject or explicitly mark the corrupted signature unsupported/malformed rather than silently accepting it as a valid container. The repository's [CCOB fixture producer](https://github.com/morluto/rea/blob/bc411c24befceced5a9ea1ca1c1ce123fd02bf48/tests/fixtures/gpu/codeObjects.ts#L310-L336) writes the literal signature, and the [recognition branch](https://github.com/morluto/rea/blob/bc411c24befceced5a9ea1ca1c1ce123fd02bf48/src/gpu/GpuInventory.ts#L148-L150) explicitly identifies this spelling. ## Impact and scope A damaged container header is silently normalized into a recognized, completely inspected GPU artifact. This creates incorrect format/completeness evidence for these bounded inputs. Both standalone CCOB and an ELF-embedded CCOB were observed. Valid fixtures still decode normally; no file mutation, crash, GPU execution, or security impact was observed. Frequency in real artifacts and other signature-bit combinations were not measured. Callers can check the first four container bytes for exact equality before inspection; the retained fixtures directly distinguish the clean and corrupted signatures. ## REA version Main source `bc411c24befceced5a9ea1ca1c1ce123fd02bf48`, package metadata `6.7.0`, was executed through the source service. Separately, the installed published `rea-agents` package also reports metadata version `6.7.0`, but its CLI returned `COMMAND_NOT_FOUND` for `inspect-gpu-code-objects`. This is a main-source finding; published-release parser behavior was not established. ## Runtime and platform Node.js v24.22.1; Linux 7.2.8-9-omarchy x86_64; repository-locked tsx loader. No GPU toolkit or external analysis provider. ## Target and artifact context Synthetic CCOB v3 zlib container around a Clang HIP bundle with one AMDGPU MessagePack kernel declaration; also wrapped in a synthetic ELF64 x86_64 `.hip_fatbin` section. The negative control changes the first byte to ASCII `D`; all payload, length and digest bytes remain unchanged between the standalone signature cases. These are format fixtures, not complete executable GPU programs. ## Interface Other — production `GpuCodeObjectsService.inspect`. Main CLI and MCP transports were not executed; the published CLI command-discovery attempt is reported separately above. ## Earliest failure stage Native analysis or reconstruction ## Relevant output or evidence Selected fields from the observed service output: ```text case first bytes ok format discovery payloads kernels ccob-clean 43434f42 true hip-bundle complete complete add_one ccob-high-bit c3434f42 true hip-bundle complete complete add_one ccob-wrong 44434f42 false AnalysisUnsupportedTargetError elf-high-bit 7f454c46 true elf complete complete add_one ``` Every object in both accepted high-bit cases had `inspection: "complete"` and an empty limitations array. In the ELF case, the corrupted CCOB signature is inside `.hip_fatbin`, rather than at the root ELF signature. - Expected source: exact signature written by the fixture producer and intended comparison in the recognition branch linked above. - Failure source: executed production source-service probe and output above. - Evidence provenance: observed. - Local verification: reproduced. - Reproduction completeness: complete for the synthetic service cases. ## Typed outcome or recovery expected Return an unsupported/malformed signature outcome for the standalone corrupted CCOB, and preserve an explicit incomplete/refused embedded payload for the ELF case. Keep the unmodified container successful. ## Analysis or suspected cause Source-derived: both [standalone recognition](https://github.com/morluto/rea/blob/bc411c24befceced5a9ea1ca1c1ce123fd02bf48/src/gpu/GpuInventory.ts#L148-L150) and [the HIP container loop](https://github.com/morluto/rea/blob/bc411c24befceced5a9ea1ca1c1ce123fd02bf48/src/gpu/GpuInventory.ts#L534-L537) compare `Buffer.toString("ascii")` with `"CCOB"`. The observed probe prints `ascii: "CCOB"` for `c3434f42`: that decoder strips the high bit. The [header reader](https://github.com/morluto/rea/blob/bc411c24befceced5a9ea1ca1c1ce123fd02bf48/src/gpu/ClangOffloadBundle.ts#L87-L116) then validates lengths and versions without rechecking the signature bytes. Comparing the original bytes at the owning signature boundary would avoid this lossy interpretation. ## Additional context Compared against the supplied open-issue snapshot and focused open/closed repository searches. [#6703](https://github.com/morluto/rea/issues/6703) concerns CCOB v1 consuming later aligned bundles; this report uses a single v3 container and an invalid magic byte. [#6719](https://github.com/morluto/rea/issues/6719) and [#6704](https://github.com/morluto/rea/issues/6704) concern HIP target spellings; [#6718](https://github.com/morluto/rea/issues/6718) concerns a legacy CUDA compression flag. None describes this exact-byte signature recognition failure. Closed [#2343](https://github.com/morluto/rea/issues/2343) reports the same lossy ASCII-decoding pattern in `src/domain/dosMz.ts` for Windows signatures; this finding is in the separate CCOB reader and GPU workflow, and does not duplicate that Windows-header behavior. PTX parsing, GGUF and Safetensors were excluded. Real compiler-produced damaged artifacts, other CCOB versions/codecs, other platforms, and first affected revision are NOT_ENOUGH_INFO. Prepared with AI assistance. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: The observed source service turns an invalid container signature into successful recognized GPU evidence with complete coverage in two container contexts, without changing the input. - Workaround status: available - Workaround basis: An exact four-byte signature comparison distinguishes the retained clean and corrupted samples before inspection; valid CCOB bytes remain accepted. Callers must locate embedded container ranges to apply this check there.

bsakaguchi closed this issue

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

bsakaguchi referenced this issue

2026-10-31 01:11:32 +00:00

[PR #4100] [MERGED] fix(artifacts): never count occurrences on an unknown duplicate path as unchanged #6058