DF-3578 — Divide-by-zero kernel panic in iwn4965_set_txpower() via malicious EEPROM

What this is

Evidence pack for a division by zero in sys/dev/netif/iwn/if_iwn.c:5707-5715 (iwn4965_set_txpower()), reachable with attacker-controlled EEPROM contents (malicious/corrupt card — the pass-2 strategy's "EEPROM parse" surface).

Root cause

iwn4965_read_eeprom() bulk-loads the power-group sample table straight from EEPROM with no validation (if_iwn.c:2314):

iwn_read_prom_data(sc, IWN4965_EEPROM_BANDS, sc->bands, sizeof sc->bands);

iwn4965_set_txpower() then interpolates between the two per-band channel samples (if_iwn.c:5707-5715):

power = interpolate(chan, chans[0].num, chans[0].samples[c][1].power,
                           chans[1].num, chans[1].samples[c][1].power, 1);

with (if_iwn.c:5632-5637):

#define fdivround(a, b, n)   ((((1 << n) * (a)) / (b) + (1 << n) / 2) / (1 << n))
#define interpolate(x, x1, y1, x2, y2, n) \
        ((y1) + fdivround(((int)(x) - (x1)) * ((y2) - (y1)), (x2) - (x1), n))

The divisor is (x2) - (x1) = chans[1].num - chans[0].num, both raw EEPROM bytes. If a malicious EEPROM stores the same channel number in both sample slots, the divisor is 0 → integer divide error → kernel panic on ifconfig wlan0 up (iwn_config → ops->set_txpower, if_iwn.c:6798) and again from iwn_auth (if_iwn.c:7199) / 4965 temperature recalibration.

Contrast: the neighboring EEPROM values are range-checked (maxpwr5GHz/maxpwr2GHz, if_iwn.c:2305-2309) — the band sample channels are not.

What this pack proves

iwn_eeprom_div0.c runs the verbatim macros with EEPROM-fed values routed through volatile storage (so the compiler cannot constant-fold the division — the first, non-volatile harness version was folded by gcc -O2 and did not fault; see VERDICT.md):

• control (chans[].num = 36/64): interpolates fine, prints power=40 OK.
• malicious (chans[].num = 36/36): SIGFPE, exit 136, deterministic 4/4.

In the kernel the same idiv raises #DE → panic. Full in-kernel repro needs a 4965 card with a re-flashed EEPROM, which the audit guest (virtio-only, no Intel WiFi device) cannot provide.

Build / run (on the DragonFly guest)

cc -O2 -Wall -o iwn_eeprom_div0 iwn_eeprom_div0.c
./iwn_eeprom_div0       # expect: control OK, then SIGFPE (exit 136)

Fix

fix.diff — guard the interpolation divisor (skip/clamp when chans[1].num <= chans[0].num), and/or validate the band table after iwn_read_prom_data.

DF-3578 — VERDICT

Status: inconclusive (runtime; no iwn/4965 hardware on guest), source-certain. Impact: kernel panic (#DE) at device bring-up. Reproduced: the fault primitive.

Root cause (verified in-tree)

• EEPROM bulk-read without validation: if_iwn.c:2314 (iwn_read_prom_data(sc, IWN4965_EEPROM_BANDS, sc->bands, sizeof sc->bands)).
• Interpolation divisor from two raw EEPROM bytes: if_iwn.c:5707-5715 calls interpolate(chan, chans[0].num, ..., chans[1].num, ..., 1); the macro (if_iwn.c:5633-5637) divides by (x2) - (x1) — zero when both sample slots carry the same channel number.
• Reachability: iwn4965_set_txpower is called from iwn_config (if_iwn.c:6798, every device bring-up), iwn_auth (if_iwn.c:7199) and iwn4965_power_calibration (if_iwn.c:5619, on temperature change). Nothing between the EEPROM read and the division validates the sample channel numbers.

Threat model: the malicious input is the card's EEPROM/OTPROM — i.e. a malicious or tampered Mini-PCIe card inserted into the machine, matching the audit strategy's "EEPROM parse — attacker-controlled on malicious card" surface. Severity Low (physical insertion / root-controlled flashing), but the fault itself is unconditional once such EEPROM contents exist.

Reproduction

iwn_eeprom_div0.c executes the verbatim fdivround/interpolate macros with the two divisor operands taken from volatile stores (modeling iwn_read_prom_data() output — runtime-opaque to the compiler):

• control (36/64): prints control (nums 36/64): power=40 OK.
• malicious (36/36): prints the marker, then SIGFPE exit 136, 4/4 runs (run.log + run.2.log stress 3/3).

PoC iteration note (recorded for honesty): the first harness version kept the sample values in a plain local struct; gcc 8.3 -O2 scalar-replaced the whole struct, constant-folded the compile-time-visible 0/0 UB, and the process survived — a classic way a div-by-zero PoC silently degrades. Moving the values behind volatile restored the real hardware idiv fault. The kernel always performs the real division (values come from DMA/MMIO reads).

Why not "reproduced"

Same reason as DF-3576: the guest is virtio-only (no Intel WiFi hardware), so the in-kernel path (EEPROM read → set_txpower) cannot be driven. The arithmetic primitive is proven deterministically; the chain is proven by source.

Fix

fix.diff guards the interpolation: only interpolate when chans[1].num > chans[0].num, else fall back to chans[0]'s sample values. (Belt-and-braces: validate the whole sc->bands table after iwn4965_read_eeprom — check lo <= chans[i].num <= hi and increasing sample channel numbers.)

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.