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:

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

DF-3694 VERDICT

Status: inconclusive (runtime) / certain (source). impact: leak (partial pointer disclosure; not demonstrated at runtime).

Why inconclusive at runtime

VIA and JMicron formats are vendor-gated (ata-raid.c:1433-1435, :1460-1462). The guest has no VIA/JMicron controller, so neither write path can execute here. The JMicron/VIA write functions are only dispatched from ata_raid_write_metadata for arrays of those formats — no other caller.

Why the source claim is certain

• :2736 meta->disks[disk] = (u_int32_t)(uintptr_t)rdp->disks[disk].dev; (JMicron, executed when serial[0]==0 — true for every ioctl-created array since ata_raid_create kmallocs with M_ZERO and never sets serials) and :3986 (VIA, unconditional for all members).
• The value lands inside the checksummed metadata block that ata_raid_rw(..., ATA_R_WRITE|ATA_R_DIRECT) persists to each member disk (:2753-2756, :4005-4008).
• On-disk it is directly recoverable: read the metadata sector, subtract the known template fields → low 32 bits of a live kernel device_t.
• No conditional logic is involved; the dataflow is straight-line.

Impact ceiling

32 bits of a kernel heap pointer per array writeback — meaningful KASLR / heap-randomization erosion on systems where the pointer's high bits are otherwise known, and a durable (survives reboot) leak into disk images. Read access to member disk raw sectors is required (root / devfs-permissive operator / physical / image inspection). Low severity overall.

Fix

Replace both assignments with karc4random() (in fix.diff; not runtime validated on this guest for the hardware reason above — fix_status = not_testable).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.