# Free SYS_DRV `.54` `0x1037`: caller-selected indefinite mailbox wait

**Conditional availability/lock-contention lead; signed-static only.**
No hardware request, live mapped register observation or second-client
failure has been made. An indefinite caller-selected timeout may be an
intentional management API, rather than a separate memory-safety bug.

`sub_E105A8` dispatches free `0x1037` with `msg[14]` and `msg[15]`
as mailbox payload scalars, `msg[16]` as timeout, and a result at
`msg[17]` to `sub_E18364`. The leaf issues `SVC 0x5E` with the
SYS_DRV-private lock ID at `0xE25774` (zero in the signed initial
image), maps **fixed fabric address `0x3B10700`** for `0x20` bytes
with `SVC 0x7D`, and polls a mapped status word. Signed sOS `.54`
`sub_59E8` cases 13 and 14 route `SVC 0x5E` and `SVC 0x5F` to its
mutex acquire/release handlers `sub_A38` and `sub_4860`; the SYS_DRV
code does not examine the acquire result. The mapped status, fabric
semantics and runtime lock ID are not measured.

At `0xE183A6..0xE183B0`, each zero-status poll computes
`timeout+1`; `timeout==0xFFFFFFFF` skips its timeout comparison and
repeats through `SVC 0x56` without a finite limit. If the first status
allows a request, the leaf writes the payload to the mapped fabric
window and has a second zero-status poll at `0xE183F2..0xE183FC`
with the **same** `timeout+1==0` bypass. The intervening 101-call
`sub_E1ECEE(10)` loop at `0xE183CE..0xE183E4` is bounded but does
not bound the subsequent poll. `SVC 0x5F` and unmap occur only on
exit at `0xE18420..0xE1842C`; a permanently zero status with
unlimited timeout would remain inside the function. A finite timeout
has an error-exit branch (`0x80000306`).

A scoped opcode-immediate scan of the selected signed ELF corpus found
no direct `0x1037` hit, but it misses computed callsites. GCP ROP
has demonstrated service-1 access to other free opcodes; this does
not prove that the fixed fabric mapping succeeds, that a status is
zero long enough, that this lock is shared with a victim, or that a
real request will hang. The prior NULL-source opcode-`0xD` test already
established a recoverable post-ROP DoS by a **different** mechanism.
Do not issue `0x1037` with an unlimited timeout or mutate the mapped
mailbox on hardware merely to obtain a return code.