DF-3367 — RTM_CHANGE with gateway == destination permanently leaks the rtentry and desynchronizes the per-CPU routing tables

Root cause (all in sys/net/route.c)

route_output_change_callback (rtsock.c:908-972) calls rt_setgate(rt, rt_key(rt), gateway) for RTM_CHANGE. For a host-gateway route whose new gateway equals its own destination, rt_setgate hits the EADDRNOTAVAIL path (route.c:1193-1205): it deletes the route from the current CPU's tree via a nested rtrequest(RTM_DELETE, ...) and returns an error.

Refcount trace at that moment (rtsearch_msghandler route.c:1726-1729):

• callback entry: rt->rt_refcnt++ → 1
• nested RTM_DELETE (route.c:824 ++rt->rt_refcnt → 2; route.c:866 rtfree → 1; route removed from tree, RTF_UP cleared, rt_key/rt_ifa intact)
• callback returns error → rt->rt_refcnt-- → 0

Nobody holds a pointer anymore: the rtentry, its key chunk, and its ifa reference are never released — a permanent leak on that CPU. Because rtsearch_msghandler replies (and stops) on the first CPU error (route.c:1751), CPUs 1..N-1 never run the change and keep the route: the per-CPU tables diverge. A later RTM_ADD of the same destination then succeeds on CPU0 and fails EEXIST on CPU1 → guaranteed panic("rtrequest1_msghandler: rtrequest table req ...") (route.c:763-768). (The panic leg was traced but deliberately not triggered during verification; the leak and divergence legs were verified empirically.)

Threat

Trigger requires routing-socket write privilege (root), so this is a robustness/lifetime bug, not an escalation: a privileged (or compromised routing daemon, e.g. via route(8)) process can permanently consume kernel memory and panic the system.

Verified on the guest (leakcheck.log / leakcheck2.log)

BEFORE
           routetbl   1.48K    257K       0    390M    3.16K
AFTER-200-CYCLES
           routetbl   3.82K    669K       0    390M    5.89K
routes visible on cpu0: 0
delete host 10.99.2.1
rc=0            <-- succeeded although cpu0 has no such route:
                    cpus 1..5 still do (divergence proven)

200 add+change cycles (+2340 in-use routetbl allocations, +412 KB); every route is invisible on cpu0 yet still present on the other CPUs; cpu0's copies are out-of-tree with refcount 0 — unfreeable.

Fix sketch

In rtsearch_msghandler, drop the temporary reference via rtfree()-safe logic (e.g. RTFREE(rt) after the callback — route.h:446 decrements and finalizes at 0), or make rt_setgate's EADDRNOTAVAIL path not mutate the tree and instead return the error to the outer RTM_CHANGE, which should then fail cleanly on every CPU. Also revisit rtredirect_oncpu (route.c:425, DF-0399) which reaches the same nested-delete with the return value ignored.