DF-5482 — efi_enter()/efi_leave() are not re-entrancy-safe despite LK_CANRECURSE: a nested efi_enter() clobbers the global efi_savevm and the outer efi_leave() then restores a NULL vmspace → pmap_setlwpvm(NULL) panic. Latent landmine (no nested path exists today).

FILE: sys/platform/pc64/x86_64/efirt.c (pass 2)

ROOT CAUSE (path:line): * efirt.c:396: efi_lock is created LK_CANRECURSE — recursion is explicitly permitted by the lock, advertising nested EFI calls as legal. * efirt.c:352: efi_enter() unconditionally does efi_savevm = td->td_lwp->lwp_vmspace; — on a nested entry (same thread, already inside the window) lwp_vmspace is ALREADY efi_vmspace, so the outer context is lost. * efirt.c:367-370: efi_leave() restores pmap_setlwpvm(td->td_lwp, efi_savevm) and then sets efi_savevm = NULL — the inner leave leaves the thread on efi_vmspace with efi_savevm == NULL; the outer leave then calls pmap_setlwpvm(lp, NULL) → lp->lwp_vmspace = NULL → vmspace_pmap(NULL) deref (pmap.c:6408-6410) → NULL-pointer panic.

REACHABILITY: none today — every efi_ entry point calls efi_enter() exactly once and firmware does not re-enter the kernel. The hazard fires the day any nested path appears (e.g. an eventhandler or var-service callback issuing another efi_ from inside the window, which is precisely what LK_CANRECURSE invites). Defensive/hardening finding: make the lock non-recursive (turn silent recursion into a deadlock/LKpanic at dev time) or track nesting depth per-thread and save/restore lwp_vmspace on a stack.

PACK: analysis-only; untested by design (Info hardening class).

DF-5482 VERDICT — efi_enter/efi_leave reentrancy landmine (latent)

Status: untested (Info hardening class; no reachable nested path exists today — nothing to reproduce by construction).

Trace

1. lockinit(&efi_lock, "efi", 0, LK_CANRECURSE) (efirt.c:396) — nested acquisition by the same thread is permitted.
2. Nested efi_enter() (same thread): efi_savevm = td->td_lwp->lwp_vmspace (efirt.c:352) now stores efi_vmspace (set by the outer entry via pmap_setlwpvm), destroying the saved user context.
3. Inner efi_leave(): pmap_setlwpvm(td->td_lwp, efi_savevm) restores efi_vmspace onto itself; efi_savevm = NULL (efirt.c:367-370).
4. Outer efi_leave(): pmap_setlwpvm(td->td_lwp, NULL) → lp->lwp_vmspace = NULL (pmap.c:6408) → pmap = vmspace_pmap(newvm) (pmap.c:6410) dereferences NULL → panic.

No current caller nests (all six entry points wrap one efi_enter; the firmware cannot call back into the kernel), so this is latent. The mismatch between the lock advertising recursion and the save/restore machinery being single-flight is the defect; simplest fix: drop LK_CANRECURSE from efi_lock so any future nesting fails loudly at development time (or add a per-thread depth counter).

Verification

None possible/needed: the trigger path does not exist in the current call graph (verified by reading all callers of efi_enter: efirt.c:496, 525, 540, 569, 584, 600 — each wrapped once, no nesting possible from firmware side). Filed as Info so the landmine is on record.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.

(No fix.diff for this item: documented recommendation only - see Fix above.)