# DF-3694 — VIA / JMicron metadata writeback persists kernel pointer bits on disk

## Root cause (source)
Both vendor write paths store truncated kernel pointers as on-disk disk IDs:

```c
2736 (jmicron):  meta->disks[disk] = (u_int32_t)(uintptr_t)rdp->disks[disk].dev;
3986 (via):      meta->disks[disk] = (u_int32_t)(uintptr_t)rdp->disks[disk].dev;
```

- JMicron (`:2732-2737`): used when a member disk has no stored serial —
  i.e. for **every ioctl-created array** (ata_raid_create never populates
  serials).
- VIA (`:3985-3986`): used **unconditionally** for every member.

The metadata block (checksummed) is then written to each member disk
(`:2753-2756`, `:4005-4008`). Anyone who can later read raw sectors of the
member disk (operator group on the raw /dev/adX node, physical access,
cloud image inspection) recovers the low 32 bits of live kernel `device_t`
pointers — defeating heap/KASLR randomization to that extent
(CWE-200/524). Writeback happens on array state changes (see DF-3693
triggers), including the boot-time 0→READY transition and
`atacontrol`-driven events.

## Guest testability
VIA and JMicron formats are only parsed on matching PCI vendors
(`ata_raid_read_metadata:1433-1435`, `:1460-1462`); this guest has Intel IDE
only → **inconclusive** (cannot instantiate the format on this hardware).
Source analysis is certain: the pointer→u32→disk dataflow has no
conditional to argue about.

## Fix
fix.diff replaces both with `karc4random()` (no kernel-derived value is
persisted; the on-disk ID is only matched against itself on re-parse).

## Files
`analysis.txt`, `fix.diff`, `verdict.json`