Summary

When a target CPU fails to service an Xinvltlb IPI for >2 seconds, the LOOPRECOVER watchdog in the done-drain wait loops of pmap_inval_smp() and pmap_inval_smp_cmpset() force-zeros info->done to escape the wait, then immediately overwrites info->{va, ptep, npte, npgs, mode} for a brand-new command and ultimately returns success (opte/success = 1) to the caller. A target that was still responsible for the PRIOR command's invalidation has its done bit wiped without ever executing cpu_invlpg(); when it eventually resumes it observes done == 0 (pmap_inval_intr:696) and skips. The prior invalidation is therefore lost on that CPU. Because the caller (pmap.c) treats the returned completion as authoritative, it frees or remaps the underlying page while the lagging CPU still holds a TLB entry mapping the old virtual address to the now-freed physical page — a use-after-free / kernel-information-leak window when that CPU resumes and touches the stale VA. The info->failed flag set at :345 / :494 / :786 is dead — no code path ever reads it, so callers cannot detect the lost invalidation.

Root cause

The wait at pmap_inval.c:342 (while (CPUMASK_TESTNZERO(info->done))) blocks a NEW pmap_inval_smp() call until every target of the PREVIOUS command (issued from the same originator CPU) has cleared its done bit. Per the target state machine, a target only clears its done bit at :764 AFTER it has executed cpu_invlpg() at :760 — therefore a still-set done bit means the target has NOT YET flushed that VA from its TLB.

The watchdog recovery at :344-349:

/* pmap_inval.c:344-349 — the bug */
if (loopwdog(info)) {
    info->failed = 1;
    loopdebug("A", info);
    /* XXX recover from possible bug */
    CPUMASK_ASSZERO(info->done);
}

unconditionally zeros info->done and falls through, so the originator proceeds to overwrite the command slot at :363-372 (info->va / npgs / ptep / npte / mode = new values), issue the new command at :418, and return the new opte at :419. The abandoned target, on its next Xinvltlb entry, tests CPUMASK_TESTBIT(info->done, cpu) at :696 against the NEW command's mask; if it is not in the new mask it continues and the OLD command's cpu_invlpg() is never executed.

The identical pattern exists for the cmpset variant at :491-499 (loop "B"). Contrast the sibling originator-quiesce wait "C" at :768-799, which on timeout does NOT abandon the command — it re-broadcasts the IPI (ATOMIC_CPUMASK_NANDMASK(smp_smurf_mask, info->mask); smp_invlpg(&smp_active_mask);) and keeps looping. The author's own /* XXX recover from possible bug */ comment marks this as a known-unsafe recovery. The precondition is a target CPU unresponsive to Xinvltlb for LOOPRECOVER_TIMEOUT1 (2 s, :78); the code comment at :73-77 explicitly anticipates this: "VMs could be very slow at handling IPIs."

Threat model & preconditions

• Attacker position: An adversary who can cause a target CPU/vCPU to be descheduled or stalled for >= 2 seconds while a pmap invalidation is pending against it. On bare metal this is not practically triggerable by an unprivileged local user (Xinvltlb ignores critical sections and fires at interrupt level — mp_machdep.c:1166-1168), so it requires an SMI storm, a wedged CPU, or a prior kernel bug. In a virtualised DragonFly guest the precondition is realistic and out of the guest's control: a hostile or heavily-oversubscribed host can starve a vCPU of CPU time for seconds (the scenario the watchdog exists for). A co-tenant causing CPU pressure, or a malicious host, can induce it.
• Privileges gained or impact: Stale TLB on the lagging CPU maps a VA to a physical page the kernel has already freed (or remapped to a different object). When that CPU resumes and touches the VA it reads/writes freed/reused memory — kernel information leak (KASLR / neighbour-secret disclosure via stale mapping of a reallocated page) or kernel memory corruption / privilege escalation via use-after-free on a freed kernel page that was reused for a privileged object. Because pmap_inval_smp / cmpset serialise ALL PTE mutations (user munmap / mprotect / exit, kernel pmap_kenter, COW, pagetable teardown), the stale-VA surface is the entire address space of the affected pmap.
• Required config or capabilities: Default kernel. options LOOPRECOVER is on by default (pc64/conf/DEFAULTS).
• Reachability: Trigger is CPU starvation > 2 s during a pending TLB shootdown — see PoC.

Proof of concept

Reproduces in the audit's QEMU/KVM guest (single-tenant, host-controllable scheduling).

1. Boot a >= 2-vCPU DragonFly guest.
2. From the host, dedicate host pCPU 1 to vCPU 1 (qemu -smp 2 -vcpu 0:affinity=0 -vcpu 1:affinity=1 or taskset on the vCPU threads) and run a SCHED_FIFO busy loop on host pCPU 1 for ~2.5 s to starve vCPU 1 of all host time — vCPU 1 cannot service its queued Xinvltlb.
3. Inside the guest on vCPU 0, run a program that: - mmaps an anon page at a fixed VA, - writes a known sentinel to it, - forks a child that pins itself to vCPU 1 and spins reading the VA, - meanwhile the parent (vCPU 0) munmap+re-mmaps the VA in a tight loop against an object that recycles the freed physical page (e.g. another mmap that grabs the just-freed page) or directly triggers pmap_kenter on the freed page.
4. At t = 2 s the watchdog "A" fires on vCPU 0 (set pmap_inval_watchdog_print = 1 first to see the ipilost-A! kprintf via loopdebug at :197), force-clears info->done, and vCPU 0's pmap operation returns "success" and frees the page.
5. Release the host busy loop; vCPU 1 resumes, its TLB still maps the old VA to the now-freed physical page, the child's read returns the sentinel (or, if the page was reused, the contents of whatever kernel/user object now occupies that physical frame) — a confirmed stale-TLB read of freed/reused memory.

Materialisation to root: once the stale-read primitive is confirmed, groom the freed page (e.g. via msgget / pipe buffers) into a privileged structure and let the lagging CPU's stale-write path corrupt it.

The minimal trigger source and a host-side vm.sh vCPU-stall helper belong in findings/poc/DF-1061/. The static verification fallback (no QEMU required):

1. Confirm CPUMASK_ASSZERO(info->done) at pmap_inval.c:348 and :498 are the force-clears in the "A" and "B" paths.
2. Confirm info->failed is never read by any caller (grep info->failed in pmap.c and pmap_inval.c returns only writers, no readers).
3. Confirm the target clears its done bit only AFTER cpu_invlpg() (pmap_inval.c:760 → :764).
4. Confirm the "C" path at :768-799 does NOT abandon the command — it re-broadcasts.

Impact

Stale-TLB use-after-free / kernel info leak when a vCPU is starved of CPU time for > 2 s during a pending TLB shootdown. Bare-metal requires extraordinary conditions (SMI storm, wedged CPU, prior bug); virtualised environments are realistic because a hostile host or a co-tenant CPU-pressure attack can induce vCPU starvation. The author's /* XXX recover from possible bug */ comment acknowledges the unsafe recovery. Medium severity per "info leak of limited kernel memory" + "requires unusual config" (heavy oversubscription / hostile host).

Recommended fix

The force-clear abandons an invalidation that the contract requires. The safe sibling recovery (loop "C" at :785-799) re-broadcasts; the done-drain wait cannot do that because the slot is about to be reused. The minimal correct fix is to fail safe: panic with a diagnostic rather than silently dropping the invalidation, since a CPU unresponsive to an Xinvltlb ACK for > 2 s is already a catastrophic system state and silent corruption is worse than a loud halt. (A liveness-preserving alternative — broadcasting a non-blocking global flush and forcing the lagging CPU to cpu_invltlb() rather than invlpg on resume — is a larger change best left to the maintainer.)

--- a/sys/platform/pc64/x86_64/pmap_inval.c
+++ b/sys/platform/pc64/x86_64/pmap_inval.c
@@ -342,11 +342,21 @@ pmap_inval_smp(pmap_t pmap, vm_offset_t va, vm_pindex_t npgs,
    while (CPUMASK_TESTNZERO(info->done)) {
 #ifdef LOOPRECOVER
        if (loopwdog(info)) {
-           info->failed = 1;
-           loopdebug("A", info);
-           /* XXX recover from possible bug */
-           CPUMASK_ASSZERO(info->done);
+           /*
+            * A target cpu has not acknowledged the PRIOR shootdown
+            * for >LOOPRECOVER_TIMEOUT1 seconds.  Its done bit being
+            * still set means it has NOT yet executed cpu_invlpg()
+            * for that command (targets clear done only AFTER invlpg,
+            * pmap_inval_intr line 760->764).  Force-clearing done
+            * here would silently lose that target's TLB invalidation:
+            * the caller would free/remap the page while the lagging
+            * cpu retains a stale TLB entry -> use-after-free / info
+            * leak when it resumes.  Fail safe instead of corrupting.
+            */
+           loopdebug("A-stuck", info);
+           panic("pmap_inval_smp: cpu %d prior shootdown unacked "
+                 ">%ds, done=%08jx mask=%08jx (stale TLB risk)",
+                 cpu, LOOPRECOVER_TIMEOUT1, info->done.ary[0],
+                 info->mask.ary[0]);
        }
 #endif
        cpu_pause();
@@ -491,11 +501,21 @@ pmap_inval_smp_cmpset(pmap_t pmap, vm_offset_t va, pt_entry_t *ptep,
    while (CPUMASK_TESTNZERO(info->done)) {
 #ifdef LOOPRECOVER
        if (loopwdog(info)) {
-           info->failed = 1;
-           loopdebug("B", info);
-           /* XXX recover from possible bug */
-           CPUMASK_ASSZERO(info->done);
+           /*
+            * Same rationale as the 'A' path in pmap_inval_smp():
+            * force-clearing done loses a target's pending TLB
+            * invalidation.  Fail safe.
+            */
+           loopdebug("B-stuck", info);
+           panic("pmap_inval_smp_cmpset: cpu %d prior shootdown "
+                 "unacked >%ds, done=%08jx mask=%08jx "
+                 "(stale TLB risk)",
+                 cpu, LOOPRECOVER_TIMEOUT1, info->done.ary[0],
+                 info->mask.ary[0]);
        }
 #endif
        cpu_pause();

If the panic is unacceptable for the VM-liveness use case, the maintainer should instead: (a) remove the force-clear, (b) on watchdog expiry execute a global smp_invltlb()-equivalent that sets a per-CPU "flush-all-on-next-Xinvltlb" flag (so the lagging CPU does cpu_invltlb() rather than a targeted — and by then wrong — invlpg when it finally resumes), and (c) propagate a real failure code through info->failed / the return value so callers do not free pages against an unconfirmed invalidation.

References

• sys/platform/pc64/x86_64/pmap_inval.c:342-349 — pmap_inval_smp "A" watchdog force-clear
• sys/platform/pc64/x86_64/pmap_inval.c:491-499 — pmap_inval_smp_cmpset "B" watchdog force-clear
• sys/platform/pc64/x86_64/pmap_inval.c:760-764 — target clears done only AFTER cpu_invlpg()
• sys/platform/pc64/x86_64/pmap_inval.c:696 — target tests done bit for the NEW command
• sys/platform/pc64/x86_64/pmap_inval.c:768-799 — sibling "C" path re-broadcasts instead of abandoning
• sys/platform/pc64/x86_64/pmap_inval.c:78 — LOOPRECOVER_TIMEOUT1 = 2 s
• sys/platform/pc64/x86_64/pmap_inval.c:73-77 — author comment: "VMs could be very slow at handling IPIs"
• CWE-754 Improper Check for Unusual or Exceptional Conditions
• CWE-669 Transfer of Incomplete Resource State

Timeline

• 2026-07-14 Discovered during automated audit.