[Other] Linux AppImage: bundled ripgrep SIGSEGV and suspected static PIE relocation metadata corruption #4337

Summary

Strata Desktop's glob and grep tools were observed to fail when their bundled ripgrep (rg) process terminated with SIGSEGV.

A read-only investigation identified repeated crashes at the same relative instruction offset and structural differences between bundled rg binaries from Strata 0.2.0.x and 0.2.6.

These findings suggest a possible ELF post-processing issue involving static PIE relocation metadata.

The precise cause has not been confirmed.

Environment

• OS: Linux Mint 22.3, x86_64
• Kernel: 7.0.0-38-generic
• CPU: AMD Threadripper PRO 5955WX
• GPU: NVIDIA GeForce RTX 2080 Ti
• Examined Strata Desktop: 0.2.6, NVIDIA CUDA 13 AppImage
• Harness: @deepseek-ai/dsh 0.2.1-alpha.3
• Bundled ripgrep package: @vscode/ripgrep-linux-x64 1.18.0

Observed crashes

According to the original investigation:

• systemd-coredump recorded 64 SIGSEGV events associated with rg between October 21 and October 25, 2026.
• The events spanned five AppImage mount instances.
• All 64 records reported the same relative instruction offset: rg + 0x3ffcf1.
• Available stack traces contained one frame.
• The crash records were marked "without build-id".
• The report indicates crashes during the Strata 0.2.2 and 0.2.3 period, before the update to 0.2.6.

The crashed rg binaries were not independently compared with the binary examined from 0.2.6.

Therefore, we have not confirmed that the crashing binaries contained the same ELF modifications identified in 0.2.6.

We also do not know whether the 0.2.0 bundled binary would crash under equivalent conditions.

No direct execution test of the 0.2.6 binary was performed.

Static ELF investigation

The original investigation compared packaged rg binaries from the 0.2.0 series and 0.2.6.

It reported:

• Matching ELF build IDs.
• Identical examined .text, .rodata, .eh_frame, and .data sections.
• Differences in ELF header and relocation-related regions.
• Former .rela.dyn and .dynamic regions in the newer binary filled with 0x5A bytes.
• An additional LOAD segment.
• A DT_RUNPATH entry of $ORIGIN.

The investigation used static tools including readelf, objdump, cmp, od, and unsquashfs.

Neither binary was verified against the upstream ripgrep package.

A complete SHA-256 digest is not available in the current review materials.

Technical hypothesis

The investigated rg executable was identified as a statically linked PIE executable with self-relocating startup code.

According to the original analysis, its startup code references the original _DYNAMIC location using RIP-relative addressing.

If an ELF rewriting step moved or invalidated relocation metadata without preserving this reference, startup self-relocation might fail or be skipped.

A later operation could then encounter an invalid or unrelocated pointer.

The observed fault location was associated with a memcpy implementation containing rep movsq.

However, register values were not examined, and there is no direct evidence that an unrelocated pointer caused the fault.

The identical relative crash offset indicates a consistent failure location, not proof of the proposed mechanism.

Furthermore, unchanged examined .text contents do not establish whether the crashing historical binaries were modified or unmodified.

Possible packaging issue

The combination of:

• 0x5A bytes in former ELF metadata regions,
• an added $ORIGIN RUNPATH,
• unchanged examined code and data sections, and
• differences in ELF layout

suggests a possible ELF rewriting or RPATH/RUNPATH adjustment step.

Tools such as patchelf are possible candidates, but the responsible operation remains unidentified.

The evidence does not establish that such post-processing was the cause of the observed crashes.

Suggested maintainer investigation

1. Examine the AppImage packaging pipeline for RPATH/RUNPATH rewriting applied to bundled executables.
2. Determine whether static PIE executables are modified during packaging.
3. Compare the upstream ripgrep artifact, pre-packaging binary, and final packaged binary.
4. Verify that the PT_DYNAMIC information and startup code's _DYNAMIC reference remain consistent.
5. In a controlled environment, test the packaged rg --version and a basic search.
6. As a control, test the unmodified upstream ripgrep binary and, if available, the 0.2.0 bundled binary under comparable conditions.

Suggested regression tests

• Add CI smoke tests for the final packaged ripgrep binary, including --version and a basic search.
• For static PIE binaries, verify that the data at the _DYNAMIC location referenced by the startup code is still a valid dynamic section.
• If no modification of rg is intended, compare its final packaged bytes with the verified upstream artifact.
• If modifications are intentional, verify that only expected changes occurred and that the modified executable starts successfully.
• Ensure glob and grep failures are reported as errors rather than silently treated as zero matches.

Investigation limitations

• The original investigation did not execute either binary for direct comparison.
• The exact historical crash binaries were not independently matched to the analyzed 0.2.6 binary.
• The upstream binary was not independently verified.
• Crash register state was not examined.
• The packaging operation has not been identified.
• The proposed cause and any potential fix remain unverified.
• The behavior has not been established across other Linux installations or Strata releases.

This issue is intended to provide maintainers with actionable diagnostic findings and a falsifiable packaging-related hypothesis, rather than a definitive root-cause determination.

Thank you for looking into this issue.