thirty-ninth pass: the slot table lies outside the code image, retiring the static line

The previous pass suspected the searches were reporting their own coverage rather than
firmware behaviour, and that is now concrete. The structure identification was verified
rather than assumed, since the handler's prologue takes the accessor's result into the
register later used for the known slot fields, so the compared dword really is the slot's
first word.

A genuine detector gap was also fixed: all four previous searches matched single-register
store patterns, which cannot match store-dual or store-multiple forms. Re-running with
those included still finds zero writers.

The actual reason is that the slot table's base lies beyond the end of the loaded code
image, in a BSS or heap region the binary does not contain, so no amount of scanning this
image can find writers of that table.

The precondition is therefore not statically decidable from this image, neither reachable
nor unreachable on the available evidence, which retires the static line on this candidate
rather than resolving it. Three code-level links remain established, two preconditions
require the card, and nothing has been executed on hardware.

2 files changed, 74 insertions, 0 deletions

diff --git a/fw/AUDIT-TA-MEMSAFETY-HUNT.md b/fw/AUDIT-TA-MEMSAFETY-HUNT.md
index e362f0b..82298bc 100644
--- a/fw/AUDIT-TA-MEMSAFETY-HUNT.md
+++ b/fw/AUDIT-TA-MEMSAFETY-HUNT.md
@@ -1868,3 +1868,42 @@ candidate's arm-reachability is therefore recorded as **unresolved**, and the pr
 **Not met.** Three links of the candidate chain are established; its two preconditions (slot
 state, TA-side dword control) are unresolved, one of them now known to be beyond what static
 taint over this single image can decide. Nothing has been executed on hardware.
+
+================================================================================
+# Thirty-ninth pass: why no writer could be found — the table is outside the image
+
+The pass-38 self-check said the searches were reporting coverage rather than firmware
+behaviour. They were, and the reason is now concrete.
+
+First, the structure identification was verified rather than assumed: `sub_E1D6BC`'s prologue
+does `bl sub_E0B148 ; mov r4, r0`, and later reads `[r4,#0x48]/[r4,#0x50]` — the known slot
+fields — so `ldr r0,[r4]` at `0xe1d700` really is `slot[0]`.
+
+Second, a genuine detector gap was fixed: all four previous searches matched `str rX,[base]`
+patterns, which **cannot match `strd rA,rB,[base]` or `stm`**. Re-run including those forms:
+still zero.
+
+Third, the actual reason:
+
+```
+code image:      0xe00100 .. 0xe27790
+slot table base: 0xe575b8   -> OUTSIDE
+```
+
+The slot table is in a BSS/heap region **not contained in the loaded code blob**. No amount of
+scanning this binary can find writers of a table it does not include.
+
+**So the precondition `slot[0] == 0x70004042` is not statically decidable from this image** —
+neither reachable nor unreachable on the available evidence. That retires the static line on
+this candidate rather than resolving it.
+
+## Objective status after thirty-nine passes
+
+**Not met**, and now with a clear reason for the remaining gap rather than an open question:
+
+* established, in code: attacker content reaches `channel+0x70`; it is stored unvalidated into
+  `slot[0x14]`; that value is consumed `>> 3` as an unbounded length by a stack copy that
+  crosses a saved `lr`;
+* undecidable from this image: whether a slot can hold the state selecting the vulnerable arm,
+  and whether a host `INVOKE` payload controls the specific dword;
+* never attempted: any execution on hardware.
diff --git a/fw/CANDIDATE-SYSDRV-SMALLOPCODE-STACK-OVERFLOW.md b/fw/CANDIDATE-SYSDRV-SMALLOPCODE-STACK-OVERFLOW.md
index be55825..90ef88b 100644
--- a/fw/CANDIDATE-SYSDRV-SMALLOPCODE-STACK-OVERFLOW.md
+++ b/fw/CANDIDATE-SYSDRV-SMALLOPCODE-STACK-OVERFLOW.md
@@ -218,3 +218,38 @@ incomplete**, not that the firmware is largely dead. Candidate explanations not
 **Net effect on the candidate: the reachability of the vulnerable arm is UNRESOLVED**, and the
 earlier "evidence toward unreachable" should be discounted accordingly — a search that implies
 an absurdity is reporting on its own coverage, not on the firmware.
+
+### Why the searches found nothing: the slot table is not in the image
+
+`sub_E1D6BC`'s prologue confirms the structure identification beyond doubt:
+
+```asm
+0xe1d6c4  ldr r0, [r0]
+0xe1d6c8  bl  #0xe0b148       ; r4 = slot for the TA-supplied index
+0xe1d6cc  mov r4, r0
+...
+0xe1d6e4  ldr r0, [r4, #0x50] ; slot fields 0x48/0x4c/0x50 -- matches the known layout
+0xe1d700  ldr r0, [r4]        ; the compared dword IS slot[0]
+```
+
+So `slot[0]` genuinely holds values like `0x60000130` / `0x70004042`, and the "byte stores
+only" model had to be wrong. Extending the searches to `strd` and `stm` (which
+`str rX,[base]` patterns cannot match) still found **zero** writers — and the reason is
+simple:
+
+```
+code image:      0xe00100 .. 0xe27790
+slot table base: 0xe575b8   -> OUTSIDE the image
+```
+
+The table lives in a BSS/heap region that is **not part of the loaded code blob**. Its
+contents are established at runtime by allocation and initialisation paths whose data this
+binary does not contain, which is exactly why no writer of `slot[0]` can be found in it.
+
+**Conclusion: the slot-state precondition (`slot[0] == 0x70004042`) is NOT resolvable by
+static analysis of this image.** It is not evidence of unreachability, and it is not evidence
+of reachability. Settling it requires reading the live table on hardware, or a memory image
+that includes `0xe575b8`.
+
+This retires the static line of enquiry on this candidate. The three code-level links remain
+established; the two preconditions require the card.