DF-2932 VERDICT — REPRODUCED (leak / privacy)

Finding: the kernel's v1 UUID generator bakes two pieces of sensitive information into every UUID it hands out via the unprivileged, jail-visible uuidgen(2) syscall (sys/kern/kern_uuid.c:160-183 — no priv_check, no prison check):

1. Exact wall-clock generation time — uuid_time() (sys/kern/kern_uuid.c:99-109) uses nanotime(); the returned UUID's 60-bit timestamp is public-format 100 ns ticks since 1582-10-15.
2. The host's primary NIC MAC address — uuid_node() (sys/kern/kern_uuid.c:86-91) calls if_getanyethermac() for the real MAC and merely ORs the multicast bit into byte 0 (kern_uuid.c:90); an observer clears that single bit and recovers the exact hardware address. RFC 4122 §6 (Security Considerations) names exactly this exposure as the reason implementations moved to random node IDs; DragonFly still embeds the MAC.

Reproduction status

• Wall-clock component: reproduced end-to-end, unprivileged (uid 1001) — run.log and run.determinism.log: v1 timestamp decoded equals host wall clock to the second in 3/3 runs, version nibble 1.
• MAC component: reproduced at the helper level on the same guest — module.tap.log (KLD uuidoff.ko, shared with DF-2931's pack): for the arpcom-first interface tap0 the exact 6 bytes if_getanyethermac() returns are tap0's real MAC 00:bd:e8:3f:01:00; uuid_node() copies those 6 bytes into the UUID node field and ORs 0x01. End-to-end via the syscall requires the first IFT_ETHER interface's driver to be arpcom-first (every classic PCI NIC: em/re/bge/rl/…); this guest's first ether is vtnet, whose softc violates the arpcom-first assumption, so on this guest the syscall instead manifests DF-2931 (type-confused softc bytes in the node field). The two findings are the two branches of the same call chain and were proven in a single module dump.

Impact ceiling

Privacy/tracking, not memory corruption: hardware-address identity disclosure (host MAC persists into every v1 UUID artifact — hammer2 PFS ids via kern_uuidgen [sys/vfs/hammer2/hammer2_ioctl.c:902], disklabel64 d_stor_uuid [sys/kern/subr_disklabel64.c:472], uuidgen(1) output) and creation-time metadata for those artifacts. Jailed processes can invoke uuidgen(2) and learn the host MAC even where AF_LINK information is otherwise hidden from the jail. No write primitive — no uid=0 route; this is objective (2): the disclosure genuinely manifests, ceiling = identity + timing metadata.

Fix

Stop deriving the node from the MAC: always use read_random() + multicast bit (RFC 4122-conformant random node IDs) — fix.diff (applies cleanly to sys/kern/kern_uuid.c). This also incidentally immunizes the uuid layer against DF-2931's type-confused read; applying DF-2931's if.c fix as well is still correct for the helper itself.

fix_status: not_testable — leak-class finding; kernel-rebuild fix validation is mandated only for memory-corruption findings, and the guest was left clean.