DF-3926 — siba_cc_power_init NULL-deref panic on the suspend/resume path when no ChipCommon core was found

What

sys/dev/netif/bwn/siba/siba_core.c:

static void
siba_cc_power_init(struct siba_cc *scc)
{
    struct siba_softc *siba = scc->scc_dev->sd_bus;   /* :1042 — NO NULL check */

(its sibling siba_cc_powerup_delay has the same unguarded deref at :1071.)

Every other consumer of scc->scc_dev guards it (siba_cc_clock :786-787, siba_cc_pmu_init caller gate :210, siba_powerdown_sub :1900). The attach path is safe because siba_core_attach only calls these under if (scc->scc_dev != NULL) (siba_core.c:210-215).

The resume path is not:

siba_core_resume (siba_core.c:2236-2249)
  -> siba_cc_resume(&siba->siba_cc)        /* :2245 — unconditional */
     -> siba_cc_power_init(scc)            /* :2223 */
        -> scc->scc_dev->sd_bus            /* :1042 PANIC if scc_dev == NULL */

How scc_dev ends up NULL on a live device

siba_scan (siba_core.c:284-414) sets siba_cc.scc_dev only when some core reports SIBA_DEVID_CHIPCOMMON (:351-360). It stays NULL when: - the very first siba_switchcore(siba, 0) fails → early return (:296-298); - hardware reports siba_ndevs > SIBA_MAX_CORES → early return after the warning (:325-330) — siba_ndevs comes straight from the MMIO ChipCommon SIBA_CC_NCORES(tmp) field (:307), i.e. device-controlled; - core windows return garbage IDHIGH so no core matches CHIPCOMMON.

In all these states the bwn child is never created, but the siba PCI bus device is attached (probe matched the DID table, siba_bwn.c:91-137), so siba_bwn_suspend → siba_bwn_resume (siba_bwn.c:211-249) still run on the next suspend/resume cycle (ACPI S3, laptop lid) → deterministic NULL-deref panic at a small fixed offset (sd_bus is at offset 0 of siba_dev_softc, so the fault address is ~0).

Sibling of DF-1939 (NULL-deref in siba_bwn_read_ivar) but a distinct function/path (resume vs ivar read).

Impact

Kernel panic (NULL deref) from a suspend/resume cycle on a card whose scan failed — device-controlled preconditions (bad MMIO/NCORES), hardware-gated. Severity Low, confidence certain at source level.

Reproduce (needs a Broadcom SSB card + forced scan failure / S3 cycle)

Not possible on the audit guest: no 14e4 PCI device (env.txt).

Fix

 (move the deref below the guard:)
+   if (scc->scc_dev == NULL)
+       return;
+   siba = scc->scc_dev->sd_bus;

(also guard siba_cc_powerup_delay; see fix.diff)

DF-3926 VERDICT

status: not_reproduced (hardware-gated) | impact observed: none (potential: NULL-deref panic) | source certainty: certain

Trace

1. siba_bwn.c:140-174 — siba_bwn_attach maps BAR0 and calls siba_core_attach for any card matching the DID table (probe :121-137). Child bwn devices exist only if siba_scan found an 802.11 core; the siba bus device itself exists regardless.
2. siba_core.c:351-360 — scc_dev assigned only on a CHIPCOMMON core; NULL otherwise, including the early-return states at :296-298 (switchcore failure) and :325-330 (ndevs > SIBA_MAX_CORES, value read from device-controlled SIBA_CC_NCORES at :307).
3. siba_core.c:210-215 — attach-path callers are NULL-guarded.
4. siba_core.c:2236-2249 — siba_core_resume calls siba_cc_resume UNCONDITIONALLY; :2219-2225 siba_cc_resume calls siba_cc_power_init; :1040-1042 dereferences scc->scc_dev->sd_bus without a check → NULL deref. (siba_cc_clock in the same path is guarded :786-787 — the asymmetry is the bug.)
5. Trigger: any suspend/resume cycle with such a card (ACPI S3).

Why not reproduced

The audit guest has no Broadcom SSB card (env.txt: no 14e4 PCI device, no bwn/siba modules). The dereference is unconditional in code once the precondition holds; the only uncertainty is hardware, not logic.

Fix validation

Hardware-gated; fix.diff adds the same NULL guard the sibling functions use.

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.