DF-2931 VERDICT — REPRODUCED (leak)

Finding: if_getanyethermac() reads the "MAC" for UUID v1 node IDs by casting ifp->if_softc to struct arpcom * and copying from offsetof(struct arpcom, ac_enaddr) (sys/net/if.c:3032). That offset equals sizeof(struct ifnet) (928 on this build) and is only meaningful when the driver softc starts with struct arpcom (assumption documented at sys/net/if_var.h:153-171 and sys/net/if_arp.h:115). For drivers that use the new-bus/if_alloc() style with a separate ifnet (vtnet, ena, oce in-tree), the 6 bytes come from an arbitrary softc-relative location — driver state that is not a MAC — and flow, through uuid_node() (sys/kern/kern_uuid.c:88) and kern_uuidgen(), into every UUID returned by the unprivileged uuidgen(2) syscall. For any such driver whose softc is smaller than 928 bytes the same expression is a heap out-of-bounds read.

How it was proven

1. Trigger (unprivileged, end-to-end): /tmp/uuidleak run as uid 1001 (run.first.log): all 4 UUIDs version 1, node field 01:00:00:00:00:00, decoded v1 timestamp == host wall clock to the second. vtnet0's real MAC is 52:54:00:12:34:56 — the node is not the MAC.
2. Structural proof (KLD module uuidoff.ko): prints sizeof(struct ifnet)=928, offsetof(struct arpcom,ac_enaddr)=928, sizeof(struct vtnet_softc)=1040, and dumps the bytes at if_softc+928 for every IFT_ETHER interface: * vtnet0: 00:00:00:00:00:00 at sc+928 (== vtnet_vlan_shadow[100..101], the field that actually lives there) — this is exactly what if_getanyethermac copied into the UUID node (module.log). * tap0 (conforming, arpcom-first): bytes at sc+928 == 00:bd:e8:3f:01:00 == tap0's exact MAC (module.tap.log) — proving the read address is literally sc+928 and that on conforming drivers the real MAC is returned (that branch is finding DF-2932).
3. Determinism: 3 spaced runs (run.determinism.log): node constant 01:00:00:00:00:00, timestamp tracks wall clock — a fixed memory read, not RNG output. (If if_getanyethermac had returned ENOENT, read_random at kern_uuid.c:89 would have produced per-call random node bytes — refuted.)
4. Mutation attempt: created vlan3200 to set a bit inside vtnet_vlan_shadow (run.vlan.log): shadow stayed 0 because the vlan_config eventhandler is only registered when the VIRTIO_NET_F_CTRL_VLAN feature is negotiated (if_vtnet.c:835-848), which this QEMU does not offer. Negative result does not weaken the proof in (1)-(3); it only blocks an optional flourish.

Why the leaked bytes matter (impact ceiling)

• 6 bytes of kernel driver softc memory per call, address pinned to first_ether_softc + 928, readable by any unprivileged local user (and from jails — sys_uuidgen has no prison check), unlimited call rate.
• Content is entirely a function of the first ether driver's struct layout at offset 928: today, zeros on stock vtnet (vlan shadow), but any layout change or other non-conforming driver can put pointers/counters there; for a non-conforming softc < 928 bytes the read is heap OOB (none of the three in-tree violators is currently < 928 — vtnet=1040 — so the OOB variant is speculative for current in-tree drivers, the wrong-field leak is certain).
• Side effect: on every vtnet-based VM (the default virtio NIC), ALL hosts emit v1 UUIDs with the identical node 01:00:00:00:00:00, voiding the v1 uniqueness guarantee across machines (same node + same 100 ns tick + same 14-bit clock-seq ⇒ collision). UUIDs are used as persistent identities (hammer2 PFS ids via kern_uuidgen at sys/vfs/hammer2/hammer2_ioctl.c:902, disklabel64 d_stor_uuid at sys/kern/subr_disklabel64.c:472).

Why not uid=0

This is a read-only disclosure primitive (6 bytes at a fixed driver-determined offset, no attacker-controlled index), not a memory corruption bug — there is no write primitive to develop into an escalation chain. Primary objective (2) applies: the leak genuinely manifests; realistic ceiling is limited kernel-memory disclosure plus the cross-host v1-collision correctness break.

False-positive check

None: reproduced end-to-end unprivileged, plus in-kernel structural proof with a counter-control (tap0). The code path is mainline; no config needed beyond an ether interface existing (else the ENOENT/random path runs, which is correct behavior).

Fix

if_getanyethermac() must not derive the MAC from if_softc; it should read the link-level sockaddr that if_attach/ether_ifattach maintains for every driver style. See fix.diff (3-line change). Note DF-2932's fix (random node ids) additionally stops embedding the MAC at the uuid layer and supersedes the privacy half; both are worth applying.

fix_status: not_testable — fix validation rebuild is mandated for memory-corruption findings; this is a leak-class finding, and the guest was kept clean instead (module unloaded, tap/vlan destroyed).