⬢ DragonFlyBSD Kernel Audit
← triage · dashboard
DF-3964

Firmware-fed get_config values consumed unvalidated: PAGE_SIZE*(max_sg_count-1) maxsize underflow and cam_simq_alloc(max_requests-1) with openings=-1

Summary

hptiop_attach stores the device-fed config verbatim. io_dmat maxsize underflows to 0xFFFFFFFFFFFFF000 when max_sg_count==0; cam_simq_alloc gets openings=-1 (approx 4G) over a 256-srb pool when max_requests==0; max_devices gates target ids and cpi->max_target. mvfrey get_config validates only header size/type, never the values. Robustness/degradation (failed attach, bogus DMA geometry, CAM queue nonsense). Validate-at-attach fix.

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-3964 · 11 files
FileTypeDescriptionSize
README.md — 930 B ↓ raw
VERDICT.md — 1.4 KB ↓ raw
trigger.c — 1.7 KB view raw
build.sh — 67 B view raw
run.sh — 91 B view raw
run.log — 12 B view raw
env.txt — 1021 B view raw
fix.diff — 774 B view raw
build.log — 7.1 KB view raw
manifest.json — 370 B view raw
verdict.json — 2.7 KB view raw
README.md
↓ download raw

DF-3964 — firmware-fed adapter config consumed unvalidated: max_sg_count-1 maxsize underflow, max_requests-1 queue depth

File: sys/dev/raid/hptiop/hptiop.c (pass 2; DF-1313 covered the ioctl size check, not these attach-time consumers)

What

hptiop_attach trusts the get_config reply verbatim (1928–1933). Consumers: - io_dmat maxsize = PAGE_SIZE * (hba->max_sg_count-1) (1951): with max_sg_count==0 this is PAGE_SIZE*0xffffffff → underflowed 64-bit maxsize handed to bus_dma_tag_create (1946–1959). - cam_simq_alloc(hba->max_requests - 1) (1993,1999): max_requests==0 → openings = −1 → 4 G openings advertised over a 256-srb pool. - max_devices gates target ids (2281) and max_target (2374).

Device-gated robustness/Low: outcome is failed attach, bogus DMA geometry, or degenerate CAM behaviour — not host memory corruption by itself.

Build / Run

Hardware-gated; see trigger.c.

VERDICT.md
↓ download raw

DF-3964 verdict — certain input-validation gap, Low impact

Reproduced?

No: no HighPoint HBA on the guest (env.txt); the config block is device-fed.

Analysis

  • hptiop.c:1928-1933: all five config fields stored verbatim from the device-written block (itl/mv: DMA'd / MMIO-read reply; mvfrey: BAR0 block validated only for header size/type at 970-976 — not for the values).
  • hptiop.c:1951: PAGE_SIZE * (hba->max_sg_count-1) — bus_size_t math underflows to 0xFFFFFFFFFFFFF000 when max_sg_count==0; tag creation with that maxsize either fails (attach abort) or creates a tag whose geometry no longer matches the firmware contract.
  • hptiop.c:1993/1999: cam_simq_alloc(hba->max_requests - 1) with 0 → (unsigned)-1 openings; the SIM then believes ~4G commands fit while the srb freelist holds 256 — the get_srb failure path (2289-2294) returns CAM_BUSY so it degrades (I/O pileup) rather than corrupts.
  • Distinct from DF-1313 (ioctl-side copyin ordering + request_size trust).

Fix

fix.diff validates the three fields at attach (reject max_requests==0, floor max_sg_count/max_devices at 1).

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.

Fix verification

not_testable
baseline no→ patch + rebuild →patched clean

fix.diff adds the missing validation before the values reach bus_dma_tag_create/cam_simq_alloc; git apply --check clean fix.diff applied to the guest /usr/src copy and the hptiop.ko module rebuilt clean with -Werror (build.log; combined with the other four hptiop fix.diffs of this batch); runtime validation still impossible without the HBA.

fix.diff; fix.diff applied to the guest /usr/src copy and the hptiop.ko module rebuilt clean with -Werror (build.log; combined with the other four hptiop fix.diffs of this batch); runtime validation still impossible without the HBA.
↓ fix.diffper-fix-DF-3964

Confirmed kernel references

Detail

Evidence (decisive lines)

VERDICT.md, trigger.c (field->consumer map), env.txt, fix.diff (attach-time validation)

PoC changes

Informational trigger only.

Verified recommended fix

Validate the firmware config at attach: reject max_requests==0, floor max_sg_count and max_devices at 1 (fix.diff).

Verdict

Certain validation gap, Low impact: hptiop_attach stores the device-fed get_config reply verbatim (hptiop.c:1928-1933) and consumes it in bus_dma_tag_create with maxsize = PAGE_SIZE*(max_sg_count-1) (:1951 — underflows to ~2^64-4096 when max_sg_count==0) and cam_simq_alloc(max_requests-1) (:1993/1999 — openings = 0xffffffff when max_requests==0, over a 256-srb pool), plus target bounds at :2281/:2374. Outcomes are failed attach / bogus DMA geometry / CAM queue nonsense — robustness, not direct host memory corruption. Distinct from DF-1313 (ioctl size-check trust). Not reproduced: guest lacks the HBA.