DF-3693 — hptv2 metadata writeback reads 2048 bytes out of a 512-byte heap buffer and persists them to disk (kernel heap disclosure)

Root cause (source)

ata_raid_hptv2_write_meta (sys/dev/disk/nata/ata-raid.c:1897-1983) allocates sizeof(struct hptv2_raid_conf) = 512 bytes (:1903-1904) but issues the write with sizeof(struct promise_raid_conf) = 2048 bytes:

1903:  meta = (struct hptv2_raid_conf *)kmalloc(sizeof(struct hptv2_raid_conf), M_AR, M_WAITOK | M_ZERO);
...
1972:       if (ata_raid_rw(rdp->disks[disk].dev,
1973:               HPTV2_LBA(rdp->disks[disk].dev), meta,
1974:               sizeof(struct promise_raid_conf),      /* 2048 != 512 */
1975:               ATA_R_WRITE | ATA_R_DIRECT)) {

ata_raid_rw DMAs bcount bytes from meta to the disk (request->data = data; request->bytecount = bcount;), so 1536 bytes of kernel heap past the allocation are written into the member disks' metadata sectors (LBA 9..12). Sizes verified by compiling the packed structs from the real header on the guest (sizeof hptv2=512, sizeof promise=2048).

write_metadata routes both AR_F_HPTV2_RAID and AR_F_HPTV3_RAID arrays here (:1492-1498). The writeback fires on every array-state change (ata_raid_config_changed:977-998 forces writeback when status changes — e.g. 0→READY at boot, mirror loss, disk detach :4179, spare insertion).

Impact

Kernel heap contents (adjacent allocation data — potentially pointers, file fragments, keys) are persisted to fixed disk sectors readable by anyone with raw access to the member disk (root/operator/physical/cloud-image inspection). CWE-125/CWE-200 (OOB read → information exposure), plus corruption of the (unwritten-by-us) HPTv2 image area semantics.

Guest testability

The HPTv2/HPTv3 read parsers are only reached when pci_get_vendor(GRANDPARENT(...)) == ATA_HIGHPOINT_ID (ata_raid_read_metadata:1416-1420), i.e. on HighPoint controllers. This QEMU guest has only an Intel PIIX3 IDE controller, so the format can never be instantiated here → verdict inconclusive (not testable on this hardware), confidence in the source analysis remains certain (buffer-size mismatch is compile-time constant; sizes confirmed on the guest toolchain).

Fix

fix.diff hunk: use sizeof(struct hptv2_raid_conf) for the write length.

Files

analysis.txt (struct size transcript from the guest), fix.diff, verdict.json

DF-3693 VERDICT

Status: inconclusive (runtime) / certain (source). impact: leak (not demonstrated at runtime on this hardware).

Why inconclusive at runtime

The HPTv2/HPTv3 parsers are vendor-gated on ATA_HIGHPOINT_ID (ata-raid.c:1416-1420). The audit guest exposes only an Intel PIIX3 IDE controller (QEMU default), so AR_F_HPTV2_RAID/AR_F_HPTV3_RAID can never be instantiated and ata_raid_hptv2_write_meta cannot be reached. No other reachable route exists (write_metadata dispatches purely on rdp->format).

Why the source claim is certain

• kmalloc(sizeof(struct hptv2_raid_conf)) = 512 bytes (verified by compiling the packed struct from the real header with the guest's cc — see analysis.txt).
• The write passes sizeof(struct promise_raid_conf) = 2048 bytes to ata_raid_rw, which sets request->data = data; request->bytecount = bcount and DMAs that many bytes from the buffer to disk (ata-raid.c:4087-4131, 1972-1975).
• 1536 bytes beyond the allocation are therefore persisted into LBA 9..12 of every member disk, on every forced writeback (status change at boot, subdisk detach :4179, spare add, generation bumps).
• The overflow is compile-time-constant; there is no path-sensitive condition to dispute.

Impact ceiling

Kernel-heap-content disclosure to persistent storage. The metadata sectors are world-position-stable (HPTV2_LBA = 9) and re-readable by whoever controls the disk later (operator/physical/cloud-image). Adjacent M_AR / kmem allocations can contain pointers and file data. No write primitive, no direct kernel-execution path → Medium.

Fix

One-line: use sizeof(struct hptv2_raid_conf) as the write length (included in fix.diff; not behaviorally validated on this guest for the hardware reason above — fix_status = not_testable with this stated reason).

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.