DF-4867 — latent NULL ctlr->setmode call: ata_intel_chipinit treats any non-ENXIO return of ata_ahci_chipinit as AHCI success

• File: sys/dev/disk/nata/chipsets/ata-intel.c
• Severity: Info (hardening / fragile error-contract), confidence: certain (shape) / latent (reachability)
• Verdict: not_reproduced — traced dead on this tree (see VERDICT.md). Not a bug today; one refactor away from a boot-time NULL function-pointer call.

What the finding is

ata_intel_chipinit() (ata-intel.c:177-180) probes for AHCI mode:

if ((ctlr->chip->cfg1 == INTEL_AHCI) &&
    (pci_read_config(dev, 0x90, 1) & 0xc0) &&
    (ata_ahci_chipinit(dev) != ENXIO))
    return 0;

Any return value that is not exactly ENXIO — including any other error code — is treated as AHCI success and chipinit returns 0 immediately, skipping the compat-mode fallback at ata-intel.c:182-189 that is the only remaining place ctlr->setmode gets assigned on this path.

ata_ahci_chipinit() (ata-ahci.c:71-122) has three failure exits: - BAR(5) alloc failure → ENXIO (ata-ahci.c:82) - interrupt setup failure → ENXIO (ata-ahci.c:88) - ata_ahci_ctlr_reset() failure → return (error) — propagated verbatim (ata-ahci.c:95-98)

All of ctlr->reset/dmainit/allocate/setmode and ctlr->channels are assigned only after that point (ata-ahci.c:101-108). So if ata_ahci_ctlr_reset() ever returns anything other than ENXIO (it currently returns only ENXIO/0, but its error is propagated as a variable), ata_intel_chipinit returns 0 with:

• ctlr->setmode == NULL (compat block skipped, AHCI assignments never reached)
• controller attach continues; channel attach then runs ata_pcichannel_setmode() (ata-pci.c:857-866) → ctlr->setmode(dev, ATA_PIO_MAX) at ata-pci.c:863 → NULL function-pointer call → kernel panic during boot/attach (sink chain: ata-all.c:525 / ata-disk.c:436 → ATA_SETMODE method).

Fix

Take the AHCI path only on explicit success — see fix.diff:

-    (ata_ahci_chipinit(dev) != ENXIO))
+    (ata_ahci_chipinit(dev) == 0))

Pack contents

• VERDICT.md — full narrative + line-level trace + what was live-verified
• dmesg.txt — guest boot evidence: the audited ata-intel path runs on every boot
• env.txt — guest uname, PCI config dump of atapci0 (PIIX3), device id
• collect_live.sh — exact commands to re-collect the evidence
• fix.diff — git-apply-able one-line hardening
• manifest.json / verdict.json

How to re-run the live evidence

dfbsd-qemu/vm.sh up          # if down
./collect_live.sh            # or: dfbsd-qemu/vm.sh run_root 'dmesg | grep -E "atapci0|ata[01]:"'

Expected: atapci0: <Intel PIIX3 WDMA2 controller> + ata0/ata1 channels — proving ata_intel_ident → ata_intel_chipinit → non-SATA branch → ata_intel_new_setmode (timing tables, ata_mode2idx) executed in-bounds at boot with no anomaly.

DF-4867 VERDICT — not_reproduced (latent; path traced dead on this tree)

Bottom line

The fragile error-contract at ata-intel.c:177-180 is real and certain in shape, but it is not reachable as a bug on this tree today: ata_ahci_chipinit() can only return 0 or ENXIO, so the != ENXIO test never mistakes a failure for success. No runtime manifestation is possible, hence not_reproduced / impact none. The finding is filed as hardening: the guard is one refactor away from a boot-time NULL function-pointer call, because ata_ahci_chipinit() propagates ata_ahci_ctlr_reset()'s error verbatim (return (error); at ata-ahci.c:97) and that callee's return set is not enforced by any contract.

Line-level trace

1. sys/dev/disk/nata/chipsets/ata-intel.c:177-180 c if ((ctlr->chip->cfg1 == INTEL_AHCI) && (pci_read_config(dev, 0x90, 1) & 0xc0) && (ata_ahci_chipinit(dev) != ENXIO)) return 0; Entering the SATA branch requires chip->max_dma >= ATA_SA150 (ata-intel.c:159/166), i.e. cfg1==INTEL_AHCI entries only (ICH6+ AHCI/RAID SKUs, ata-intel.c:71-112). Requires config 0x90 bits 0xc0 set (BIOS AHCI/RAID mode).

2. ata_ahci_chipinit() return paths (sys/dev/disk/nata/chipsets/ata-ahci.c): - :80-82 BAR(5) MEMORY alloc fails → ENXIO - :85-89 ata_setup_interrupt fails → ENXIO - :95-98 ata_ahci_ctlr_reset() != 0 → return (error) — any error code propagates - :121 success → 0 (only here are ctlr->channels/:105-108 setmode etc. assigned) ata_ahci_ctlr_reset() (:124-159) currently returns only ENXIO (:141) or 0 (:159).

3. If a non-ENXIO error ever propagated: ata_intel_chipinit returns 0 at :180 with ctlr->setmode == NULL — the compat block at :182-189 (ctlr->setmode = ata_intel_sata_setmode or ata_sata_setmode) is skipped, and the AHCI block never assigned it.

4. Sink: ata_pcichannel_setmode() ata-pci.c:857-866 calls ctlr->setmode(dev, ATA_PIO_MAX) (:863) unconditionally via the ata_setmode bus method, invoked from ata-all.c:525 and ata-disk.c:436 during channel/device attach → NULL function pointer call → panic while attaching the disk subsystem.

Why not reproducible on this guest / tree

• Hardware path: requires an ICH6+ Intel SATA controller with cfg1==INTEL_AHCI, BIOS mode bits 0x90&0xc0, and an AHCI controller-reset failure returning non-ENXIO.
• Source path: with the current tree, ata_ahci_chipinit ∈ {0, ENXIO} at every exit (verified by exhaustively reading all four return sites), so the != ENXIO guard never misfires. There is no way to make ata_ahci_ctlr_reset return a third value without editing sys/ (read-only for this audit).
• Guest (QEMU PIIX3, see env.txt) has no AHCI-capable Intel SATA part at all: the boot path is the non-SATA branch (ata-intel.c:159-163), which always assigns ctlr->setmode = ata_intel_new_setmode.

What WAS live-verified (negative evidence for this file's boot path)

The guest boots on atapci0: <Intel PIIX3 WDMA2 controller> (chip 0x70108086 = ATA_I82371SB, ata-intel.c:51 → ata_intel_chipinit → non-SATA branch, channels=2, ata_intel_allocate, ata_intel_new_setmode):

• dmesg.txt: atapci0, ata0, ata1, acd0 ... WDMA2 — the setmode callback ran at attach and indexed timings[ata_mode2idx(WDMA2)] = timings[7] (in-bounds, table has 15 entries) with no anomaly.
• env.txt: PCI config dword at 0x54 = 0x00000400 — exactly the vendor-specific bit reg54 |= 0x0400 written by ata_intel_new_setmode (ata-intel.c:310). Direct register-level proof the audited function executed on this boot.
• Guest healthy throughout; no panic; guest not dirtied.

Fix validation

Not applicable (nothing to make fail on the baseline). The one-line fix.diff (!= ENXIO → == 0) is trivially semantics-preserving for every return value the callee can produce today and closes the contract hole for any future error code.

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.