[GH-ISSUE #2533] fix(ghidra): UTF-8-marked language definitions abort catalog loading #850

Closed
opened 2026-10-15 18:28:59 +00:00 by bsakaguchi · 0 comments
Owner

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

Summary

A valid Ghidra language-definition file with an initial UTF-8 byte order mark makes REA abort its entire language-catalog read. That prevents admission of a configured import language when profile resolution reaches the catalog. Removing only the mark allows the same definition to load.

Runtime or environment

Repository revision 8b181716ac, Node v26.10.0, npm 11.19.1, and locked dependencies including the XML parser. Verification exercised real filesystem catalog loading; it did not launch Ghidra or execute an end-to-end CLI analysis.

Steps to reproduce

  1. In a disposable installation root, create Ghidra/Processors/probe/data/languages/.
  2. Write probe.ldefs as UTF-8 with bytes EF BB BF immediately before this XML:
<?xml version="1.0" encoding="UTF-8"?>
<language_definitions><language id="x86:LE:32:default"/></language_definitions>
  1. Call readGhidraLanguageCatalog on the installation root. The local focused probe executed this call and observed rejection.
  2. Remove just the three signature bytes and repeat. The same probe observed a catalog containing x86:LE:32:default with no compiler specs. An unclosed-root XML control continued to throw.

The source-established analysis route requires an available Ghidra installation, a supported target profile, and REA_GHIDRA_LANGUAGE_ID=x86:LE:32:default; profile resolution then reads this catalog before admitting the override. That full provider workflow was not executed locally.

Expected behavior

The file's encoding signature should not prevent REA from reading its language definition. Marked and unmarked versions of the same valid document should yield identical catalogs. Genuinely malformed XML should continue to fail validation.

Actual behavior

The marked file rejected the catalog read with ParseError and a message reporting unexpected content outside the root element, identifying U+FEFF. The unmarked version returned the expected language. Source inspection establishes that the provider catches this read failure and returns an adapter error before admitting the requested override.

Evidence

  • Expected source: src/ghidra/GhidraLanguageCatalog.ts:62 promises reading installation language definitions; XML 1.0 section 4.3.3 permits an initial UTF-8 byte order mark and defines it as an encoding signature rather than document content.
  • Failure source: src/ghidra/GhidraLanguageCatalog.ts:79 decodes the full buffer as UTF-8, and src/ghidra/GhidraLanguageCatalog.ts:24 parses the resulting text with strict error handling. The real filesystem probe observed marked-file rejection and unmarked-file success. src/ghidra/GhidraProvider.ts:213 establishes configured-override reachability and error propagation.
  • Evidence provenance: observed
  • Local verification: reproduced
  • Reproduction completeness: complete

No matching existing issue was found in read-only searches. The file was a controlled valid XML fixture; no marked file shipped by a vendor was identified.

Restoration check

Repeat the marked-file catalog call and require the same language result as the unmarked control. Include a valid sibling definition and confirm both survive catalog loading. Preserve rejection of the unclosed-root malformed control. For an available supported provider, the marked-file catalog must no longer prevent admission of the configured language.

Triage assessment

  • Impact level: P2
  • Assessment status: supported
  • Impact basis: One valid file encoding aborts the catalog operation needed for a configured language override. The failure is bounded to installations containing such a file; population frequency was not measured.
  • Workaround status: available
  • Workaround basis: Removing only the initial UTF-8 encoding signature preserved the definition and restored the catalog result in the local control, without dropping the requested override.
Originally created by @coygeek on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2533 ## Summary A valid Ghidra language-definition file with an initial UTF-8 byte order mark makes REA abort its entire language-catalog read. That prevents admission of a configured import language when profile resolution reaches the catalog. Removing only the mark allows the same definition to load. ## Runtime or environment Repository revision 8b181716aca2cb467be499cba226abfb5ae19141, Node v26.10.0, npm 11.19.1, and locked dependencies including the XML parser. Verification exercised real filesystem catalog loading; it did not launch Ghidra or execute an end-to-end CLI analysis. ## Steps to reproduce 1. In a disposable installation root, create `Ghidra/Processors/probe/data/languages/`. 2. Write `probe.ldefs` as UTF-8 with bytes `EF BB BF` immediately before this XML: ```xml <?xml version="1.0" encoding="UTF-8"?> <language_definitions><language id="x86:LE:32:default"/></language_definitions> ``` 3. Call `readGhidraLanguageCatalog` on the installation root. The local focused probe executed this call and observed rejection. 4. Remove just the three signature bytes and repeat. The same probe observed a catalog containing `x86:LE:32:default` with no compiler specs. An unclosed-root XML control continued to throw. The source-established analysis route requires an available Ghidra installation, a supported target profile, and `REA_GHIDRA_LANGUAGE_ID=x86:LE:32:default`; profile resolution then reads this catalog before admitting the override. That full provider workflow was not executed locally. ## Expected behavior The file's encoding signature should not prevent REA from reading its language definition. Marked and unmarked versions of the same valid document should yield identical catalogs. Genuinely malformed XML should continue to fail validation. ## Actual behavior The marked file rejected the catalog read with `ParseError` and a message reporting unexpected content outside the root element, identifying U+FEFF. The unmarked version returned the expected language. Source inspection establishes that the provider catches this read failure and returns an adapter error before admitting the requested override. ## Evidence - Expected source: `src/ghidra/GhidraLanguageCatalog.ts:62` promises reading installation language definitions; [XML 1.0 section 4.3.3](https://www.w3.org/TR/xml/#charencoding) permits an initial UTF-8 byte order mark and defines it as an encoding signature rather than document content. - Failure source: `src/ghidra/GhidraLanguageCatalog.ts:79` decodes the full buffer as UTF-8, and `src/ghidra/GhidraLanguageCatalog.ts:24` parses the resulting text with strict error handling. The real filesystem probe observed marked-file rejection and unmarked-file success. `src/ghidra/GhidraProvider.ts:213` establishes configured-override reachability and error propagation. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete No matching existing issue was found in read-only searches. The file was a controlled valid XML fixture; no marked file shipped by a vendor was identified. ## Restoration check Repeat the marked-file catalog call and require the same language result as the unmarked control. Include a valid sibling definition and confirm both survive catalog loading. Preserve rejection of the unclosed-root malformed control. For an available supported provider, the marked-file catalog must no longer prevent admission of the configured language. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: One valid file encoding aborts the catalog operation needed for a configured language override. The failure is bounded to installations containing such a file; population frequency was not measured. - Workaround status: available - Workaround basis: Removing only the initial UTF-8 encoding signature preserved the definition and restored the catalog result in the local control, without dropping the requested override.
bsakaguchi 2026-10-15 18:28:59 +00:00
  • closed this issue
  • added the
    bug
    label
Sign in to join this conversation.
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#850
No description provided.