[Bug] A function is cut at a wrongly flagged no-return call (malloc, __tls_get_addr) and REA gives no warning #1658

TL;DR: On a stripped Rust library, Ghidra treats two libc calls as calls that never return. That cuts one function from 78 instructions to 8, and REA shows it with no warning. REA already has a script that undoes this for some functions, but it skips these two.

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

I pointed REA at loot.cpython-313-x86_64-linux-gnu.so with the Ghidra provider. The file is the Python module of libloot 0.29.6 (GPL-3.0-or-later). It ships inside Amethyst Mod Manager 2.5.3 (GPL-3.0-or-later). It is Rust with PyO3 0.25.1, and it is stripped.

The one exported function is PyInit_loot. REA returns this for it (the three try/catch comment lines are removed):

void PyInit_loot(void)
{
  /* WARNING: Subroutine does not return */
  __tls_get_addr(&PTR_0068ee28);
}

The assembly view stops at the same call, after 8 instructions. The procedure info says the body is 43 bytes. The function dossier returns the same body. It reports confidence: observed and only the generic limitations.

The real function is longer. In objdump -d it runs from file offset 0x3e1020 to a ud2 at 0x3e1172. That range holds 78 instructions. The code reads a thread-local counter, calls the module init, and builds the Python error on failure.

Ghidra alone gives the same result. I ran analyzeHeadless on the same file with default analysis and no REA script. The function has the same 8 instructions. The external __tls_get_addr carries the no-return flag. So Ghidra sets the flag. REA does not clear it, and it does not say the body may be cut.

The flag is wrong for more than one call. These are Ghidra's counts after default analysis, before any REA script ran:

file       call              really no-return?  sites  functions
loot       malloc            no                 1,611  840
loot       __tls_get_addr    no                 197    156
loot       _Unwind_Resume    yes                636    189
loot       abort             yes                1      1
filegraph  memcpy            no                 1,206  482
filegraph  memset            no                 187    117
filegraph  strlen            no                 217    102
filegraph  __errno_location  no                 87     45

"Sites" are the calls where Ghidra ends the flow. "Functions" is how many functions hold them. I did not measure how many of those functions are really cut. A call can end the flow while the code after it is reached some other way. PyInit_loot is cut. PyInit_amethyst_filegraph is not cut, and it decompiles in full.

Reproduction

1. Get the file from Amethyst Mod Manager 2.5.3. The v2.5.3 release has the Flatpak as AmethystModManager.flatpak. The file sits at /app/lib/python3.13/site-packages/loot.cpython-313-x86_64-linux-gnu.so inside it.
2. I took mine from an installed copy. I did not compare the release asset byte for byte (unverified). The SHA-256 of my file is 7777474017b65531258cc1678f2c1ee45e61f4b76de4890c02c7436cbbbe60a8.
3. Copy the file to a plain folder.
4. Run rea decompile /abs/path/loot.cpython-313-x86_64-linux-gnu.so PyInit_loot --provider ghidra --format json. Over MCP, call open_binary with provider_id set to ghidra. Then call procedure_pseudo_code for PyInit_loot.
5. Compare with objdump -d --start-address=0x3e1020 --stop-address=0x3e1180 on the same file.

The CLI command and the MCP route gave the same result on main.

The first import took 4 to 5 minutes here, with three or four Ghidra processes running. After open_binary, later calls on the same MCP session answered in under a second.

A small Rust library I built myself did not reproduce this. In it, __tls_get_addr was not flagged. The function decompiled in full, with 48 instructions. So the Amethyst file is needed. I do not know what makes Ghidra set the flag on this file.

Expected behavior

PyInit_loot should come back whole. If Ghidra's flag cannot be trusted, the result should say so. Today nothing tells the reader that the body may be cut at a no-return call.

Impact and scope

• Affected: the pseudo-code, the assembly, the info and the dossier. Any function that calls such an external can be hit.
• Not affected: the bytes. read_bytes at 0x4e1046 returns the call and the code after it. inspect_binary_layout is also untouched.
• Evidence integrity: the result is typed observed and carries no limitation. A caller reads PyInit_loot as a function that never returns.
• Seen on two Rust files. I have not tried C or C++ files that make the same libc calls.

REA version

Main branch, at commit 4999e4b (#1651). Its package.json says 6.3.0. The released 6.3.0 package gave the same output in an earlier run. I did not re-run it today.

Main has moved to 639b730 since then. The no-return script has not changed there. I checked with git diff.

Runtime and platform

Node 24.18.0; Nobara 44 (Fedora 44 base), Linux 7.2.9, x86-64; Ghidra 12.1.4 (Apache-2.0); JDK 21.0.12.1

Target and artifact context

ELF64 x86-64 shared object, stripped, Rust with PyO3 0.25.1, 5,836,952 bytes. A second file, amethyst_filegraph.abi3.so, was used for the filegraph rows.

Interface

MCP

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

The decompile and the table are above. These are the first lines of the real function, from objdump -d:

3e1020: push   %r14
3e1022: push   %rbx
3e1023: sub    $0xb8,%rsp
3e102a: lea    -0x30aea9(%rip),%rax
3e1031: mov    %rax,0x8(%rsp)
3e1036: movq   $0x1e,0x10(%rsp)
3e103f: lea    0x1adde2(%rip),%rdi
3e1046: call   529080 <__tls_get_addr@plt>
3e104b: mov    0x70(%rax),%rdi      <- Ghidra stops before this
...
3e1102: ret

In this file, Ghidra adds 0x100000 to file offsets. The call is at 0x4e1046 in REA.

Typed outcome or recovery expected

When a function body ends at a call whose callee has the no-return flag, the result could carry a limitation. It would name the callee.

Analysis or suspected cause

This part is read from source, and I tested the fix idea once.

The script bridge/ghidra/ReaGhidraNoReturnFix.java at 4999e4b already clears wrong no-return flags. Its rule is: flagged no-return, and the body holds a real return. Its loop skips thunks, which covers the PLT stubs. An external function has no body with a return in it. So neither one is ever cleared.

After the script ran on loot, it reported cleared=4 sites=75 refit=23. The external __tls_get_addr stayed flagged on all 197 call sites. The external malloc stayed flagged on all 1,611.

I tried a copy of that script that also clears the flag on six externals and their stubs. The six are malloc, __tls_get_addr, memcpy, memset, strlen and __errno_location. The copy then re-disassembles the call sites the same way. After that, the function came back with 59 instructions. The decompile has 74 lines. It now shows the real calls and PyErr_SetRaisedException.

That copy re-disassembled 1,812 call sites and refit 994 functions in loot. I did not check whether those refits are right (unverified). I tried it on one file.

export GHIDRA_INSTALL_DIR=/path/to/ghidra_12.1.4_PUBLIC JAVA_HOME=/path/to/jdk-21
export REA_GHIDRA_STARTUP_TIMEOUT_MS=600000

# REA
node scripts/rea.mjs decompile /abs/loot.cpython-313-x86_64-linux-gnu.so PyInit_loot --provider ghidra --format json

# Ghidra alone, with a script that prints the facts
$GHIDRA_INSTALL_DIR/support/analyzeHeadless /tmp/proj rea-project \
  -import /abs/loot.cpython-313-x86_64-linux-gnu.so -readOnly -deleteProject \
  -scriptPath /abs/scripts -postScript P4Dump2.java ghidra_default_analysis_only PyInit_ masterlist

--- bridge/ghidra/ReaGhidraNoReturnFix.java (4999e4be2)
+++ P4NoReturnExt.java (class renamed; run after the original script)
@@ -16,7 +16,7 @@
  * call as a terminator and the decompiler truncated them. Clear the flag, then re-disassemble only
  * the call sites of the functions that were cleared and refit their owning functions in place.
  */
-public final class ReaGhidraNoReturnFix extends GhidraScript {
+public final class P4NoReturnExt extends GhidraScript {
   @Override
   public void run() throws Exception {
     // Windows P0 does not admit analysis-database mutation.
@@ -24,6 +24,21 @@
     FunctionManager fm = currentProgram.getFunctionManager();
     Listing li = currentProgram.getListing();
     Set<Address> cleared = new HashSet<>();
+    Set<String> names = Set.of("__tls_get_addr", "malloc", "memcpy", "memset", "strlen", "__errno_location");
+    for (Function e : fm.getExternalFunctions()) {
+      if (names.contains(e.getName()) && e.hasNoReturn()) {
+        e.setNoReturn(false);
+        println("P4X cleared external " + e.getName());
+      }
+    }
+    for (Function t : fm.getFunctions(true)) {
+      if (!t.isThunk()) continue;
+      Function target = t.getThunkedFunction(true);
+      if (target != null && names.contains(target.getName())) {
+        if (t.hasNoReturn()) t.setNoReturn(false);
+        cleared.add(t.getEntryPoint());
+      }
+    }
     for (Function f : fm.getFunctions(true)) {
       monitor.checkCancelled();
       if (!f.hasNoReturn() || f.isThunk()) continue;

Related, but not the same, is #1244. It asks for a warning when a guessed signature clashes with the code.

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊