# 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.