DF-0315 — wg_peer use-after-free PoC

Finding: UAF — wg_peer_destroy frees the peer struct while data-plane paths (wg_output/wg_input/wg_encrypt/wg_decrypt) dereference it without a peer refcount. sys/net/wg/if_wg.c, severity High, CWE-416.

Files

Build (as maxx)

cd poc/DF-0315 && cc -O2 -pthread -o wgrace wgrace.c

Run

The racer must run as root for the SIOCSWG destroy side (SYSCAP_RESTRICTEDROOT, if_wg.c:2671). The wg_output (data-plane) side is what an unprivileged local user drives; the destroy side is what root does.

# DECISIVE DF-0315 test (isolated from the separate wg-send crash via NOEP):
ssh dfbsd
  cd ~maxx/poc/DF-0315 && env NOEP=1 NSEND=4 NGROOM=6 ./wgrace 55

# Optional: the SEPARATE wg-send crash (NOT DF-0315), for reference:
  env NOPRIV=1 NORACE=1 NSEND=1 NGROOM=0 SDELAY=2000 ./wgrace 20

Expected

• DF-0315 (decisive, NOEP) — on a vulnerable kernel that lets the UAF window be hit, a page-fault panic in the wg_output / wg_peer_send_staged path shortly after start (signature in dfbsd-qemu/boot.log). On this master DEV X86_64_GENERIC kernel it does NOT panic: the run exits cleanly after ~16.8M sends / ~22k destroy-readd cycles and the guest stays up. See VERDICT.md for why (narrow window + slow destroy + GENERIC slab leaves the freed peer's fields stale-but-valid).
• Separate crash (NOPRIV+endpoint) — panics in udp_send+0x2cf within ~20 s; this is a different bug (no peer destruction involved), documented in endpoint_crash_separate_bug.txt.

Environment knobs (env vars)

NOEP=1 peer has no endpoint (isolates the wg_output UAF from the separate wg-send crash). NOPRIV=1 omit interface private key (handshake can't be created). NORACE=1 disable destroy/re-add (control). NOGROOM=1 disable groomers. NSEND=n / NGROOM=n thread counts. SDELAY=us inter-send delay.

DF-0315 — wg_peer use-after-free in sys/net/wg/if_wg.c

Verdict: NOT REPRODUCED dynamically on this kernel — but a real, reachable, code-confirmed UAF (not a false positive)

The use-after-free described in DF-0315 is genuinely present in the code and the if_wg module is loaded and reachable on the audited master DEV guest. However, after a thorough, multi-config racing campaign I was unable to turn the destroy-race UAF into an observable kernel panic on this non-INVARIANTS X86_64_GENERIC kernel: the wg_output post-lookup window is too narrow and wg_peer_destroy() (which blocks on taskqueue_drain) too slow for the kfree(peer) to land inside it, and freeing a large object on the slab leaves the freed slot's relevant fields stale-but-valid (the slab free-list only clobbers the first word), so even a hit reads valid-looking data and does not fault. This file is the full reasoning with path:line evidence.

1. The bug, confirmed line by line (read-only sys/)

wg_peer has no refcount of its own. The data plane obtains a struct wg_peer * and uses it without holding sc->sc_lock, while the control plane frees the peer under sc->sc_lock.

• Allocation / no peer refcount — sys/net/wg/if_wg.c:226-266 (struct wg_peer); created at wg_peer_create :589 kmalloc(sizeof(*peer), M_WG, M_WAITOK|M_ZERO). Nothing counts references to the peer struct.
• The data-plane entry — wg_output :2334 peer = wg_aip_lookup(sc, af, ...). wg_aip_lookup (:854) takes sc->sc_aip_lock SHARED only to do the radix lookup and then calls noise_remote_ref(peer->p_remote) at :880 — i.e. it pins peer->p_remote (the noise_remote), not peer — and releases sc_aip_lock at :884 before returning. After the return, wg_output has a raw peer pointer with no lock and no peer refcount.
• The unprotected window — back in wg_output: peer->p_endpoint... is read at :2342-2345; wg_queue_push_staged(&peer->p_stage_queue, pkt) at :2350; wg_peer_send_staged(peer) at :2351 (which itself dereferences peer->p_sc, peer->p_stage_queue, peer->p_remote, peer->p_encrypt_serial at :2230-2269); and finally noise_remote_put(peer->p_remote) at :2352 (a UAF read of the freed peer->p_remote field). None of this holds sc->sc_lock. The same pattern recurs at the other cited sites: wg_encrypt :1849-1874, wg_decrypt :1886-1940, the wg_input data path :2187-2194, and the task handlers wg_deliver_out :1991-2034 / wg_deliver_in :2037+ (which receive the peer as a raw task argument).
• The free — wg_peer_destroy :640 (KKASSERT sc_lock EXCLUSIVE at :644) does its teardown and then kfree(peer, M_WG) at :692. It is reached from the SIOCSWG ioctl (wg_ioctl_set holds sc_lock EXCLUSIVE at :2522, calls wg_peer_destroy at :2539 and :2602; SIOCSWG requires SYSCAP_RESTRICTEDROOT at :2671). The noise_remote refcount held by the data plane keeps the remote alive but does not keep peer alive: kfree(peer) happens unconditionally at :692 regardless of outstanding remote refs.

So: peer can be kfree()d while wg_output/wg_encrypt/wg_decrypt/the deliver tasks are still dereferencing it. That is a textbook heap UAF.

2. Reachability (confirmed)

kldstat: if_wg.ko (/boot/kernel/if_wg.ko)  -- already loaded on this guest
uname:    DragonFly dfbsd 6.5-DEVELOPMENT ... X86_64_GENERIC x86_64

ifconfig wg0 create works, peers/allowed-IPs/endpoints are configurable via SIOCSWG, and bringing wg0 up installs the connected route so a local user's sendto() into the wg subnet reaches wg_output. The cited paths are live code, not behind a koption.

3. Why it did not manifest as a panic (the negative result)

I raced wg_output (senders flooding UDP into wg0) against wg_peer_destroy (root SIOCSWG REPLACE_PEERS destroy/re-add loop), with correct heap grooming: kern_exec.c:602 allocates proc args via kmalloc(sizeof(struct pargs)+i, M_PARGS); a ~700-byte argv lands in the same kmalloc-1024 zone as wg_peer (~700 B), so freed peer slots are reclaimed with foreign bytes.

The destroy race ran 16.8 million wg_output calls with the correct bucket grooming and never faulted. Root causes of the non-fault:

1. Window is too narrow. In the only stable config (peer with no endpoint), wg_output returns EHOSTUNREACH at :2346 immediately after the single peer->p_endpoint read at :2342. The window between wg_aip_lookup (:2334) and the last peer deref is a handful of instructions.
2. wg_peer_destroy is too slow to fit in that window. Destroy blocks on taskqueue_drain (:669-670) and runs five callout_terminates before reaching kfree (:692); the kfree essentially never lands inside the microsecond-scale wg_output window.
3. Slab behaviour on GENERIC. Even when a hit occurs, kfree of a ~700-byte object only overwrites the first pointer of the slab slot with the free-list link; the fields wg_output reads (p_endpoint at ~offset 140, p_stage_queue at ~offset 200+) stay stale-but-valid, so the dereference succeeds. A panic needs the freed slot to be reclaimed with foreign content AND the reclaim to land inside the tiny window — possible in principle, not achieved in 16.8M sends.

Widening the window by giving the peer an endpoint (so wg_output runs the full wg_peer_send_staged path) was blocked by a separate bug: under even trivial UDP load into a wg interface whose peer has an endpoint, the kernel panics in wg_deliver_out -> wg_send -> udp_send (current process = Idle) within ~15-20 s, with no peer destruction at all — i.e. not the DF-0315 UAF. See endpoint_crash_separate_bug.txt. That crash is reproducible (4/4) but is a distinct defect and should be filed separately.

4. What would make it fire

The UAF would reliably panic on: * an INVARIANTS/DEBUG kernel that poisons freed slab memory (the stale reads would then hit poison bytes and fault), or * a build with Witness/use-after-free detection, or * racing the taskqueue data plane (wg_encrypt/wg_decrypt/the deliver tasks, whose peer pointer is held for the whole task and is not drained for the parallel encrypt/decrypt tasks) against destroy — but that needs a completed handshake (keypair), which needs a real responding peer.

5. Suggested fix (fix.diff, verified git apply --check clean)

Add a refcount to wg_peer, take it in the data-plane entry points (wg_aip_lookup, wg_encrypt, wg_decrypt, the wg_input data path) and drop it on exit, and have wg_peer_destroy() detach the peer (so no new refs are taken) and then drop the table's reference via wg_peer_put(); the peer is freed only when the last in-flight data-plane reference is released. This mirrors the peer-refcounting used by FreeBSD's if_wg. The remaining refinement (task-lifetime refs for wg_deliver_out/wg_deliver_in, which receive the peer as a raw task argument) is noted in the diff comments; the diff as shipped closes the primary local-attack vector (wg_output / wg_aip_lookup) plus the inline encrypt/decrypt/input sites.

6. Reproduce

ssh dfbsd-maxx                # unprivileged build
  cd poc/DF-0315 && cc -O2 -pthread -o wgrace wgrace.c
ssh dfbsd                      # root run (SIOCSWG needs SYSCAP_RESTRICTEDROOT)
  cd ~maxx/poc/DF-0315 && env NOEP=1 NSEND=4 NGROOM=6 ./wgrace 55

On this kernel it exits cleanly (no panic, guest up). To see the separate wg-send crash instead: env NOPRIV=1 NORACE=1 NSEND=1 NGROOM=0 SDELAY=2000 ./wgrace 20 → panic in udp_send+0x2cf within ~20 s (NOT DF-0315).