# DF-4873 — ath_hal_9287EepromAttach error paths leak the malloc'd HAL_EEPROM_9287 (~1KB per failed attach; ar9287Attach's `bad:` path cannot reclaim it)

## What was verified (static, line-by-line)

1. **The allocation.** `sys/dev/netif/ath/ath_hal/ah_eeprom_9287.c:322-326`
   ```c
   ee = ath_hal_malloc(sizeof(HAL_EEPROM_9287));
   if (ee == AH_NULL)
       return HAL_ENOMEM;
   ```
   `ath_hal_malloc` = `kmalloc(size, M_ATH_HAL, M_INTWAIT | M_ZERO)`
   (`ah_osdep.c:121-124`). `sizeof(HAL_EEPROM_9287)` ≈ 1 KB (ee_base ~0x3d0
   bytes + `ee_rdEdgesPower[8*12]` = 96 × sizeof(RD_EDGES_POWER)).

2. **Three error returns after the allocation, none free it.**
   - mid-image read failure → `return HAL_EEREAD;` (ah_eeprom_9287.c:331-336)
   - bad checksum → `return HAL_EEBADSUM;` (ah_eeprom_9287.c:373-377)
   - bad EEPROM version → `return HAL_EEBADSUM;` (ah_eeprom_9287.c:392-396)

3. **Ownership is never transferred on those paths.** `AH_PRIVATE(ah)->ah_eeprom`
   and the `ah_eepromDetach`/`ah_eepromGet`/... ops are installed only at the
   very end (ah_eeprom_9287.c:400-406), after all of the error returns.

4. **The caller's unwind cannot reclaim it.** `ar9287Attach`
   (`sys/dev/netif/ath/ath_hal/ar9002/ar9287_attach.c:239-241`):
   ```c
   ecode = ath_hal_9287EepromAttach(ah);
   if (ecode != HAL_OK)
       goto bad;              /* ar9287_attach.c:362-367 */
   bad:
       if (ah != AH_NULL)
           ah->ah_detach(ah); /* == ar5416Detach (ar5416_attach.c:97) */
   ```
   `ar5416Detach` (`ar5416_attach.c:490-509`) calls `ath_hal_eepromDetach(ah)`
   at line 507, which is the macro
   ```c
   #define ath_hal_eepromDetach(_ah) do {                        \
       if (AH_PRIVATE(_ah)->ah_eepromDetach != AH_NULL)          \
           AH_PRIVATE(_ah)->ah_eepromDetach(_ah);                \
   } while (0)                                                   /* ah_internal.h:474-477 */
   ```
   — a no-op because `ah_eepromDetach` was never installed — then
   `ath_hal_free(ah)` frees only the `struct ath_hal_9287`, not `ee`.
   The ~1 KB `HAL_EEPROM_9287` is orphaned. **Leak confirmed.**

5. **Family bug.** `v14EepromAttach` has the identical shape
   (`ah_eeprom_v14.c:363` malloc; `return HAL_EEREAD` at ~:375 with no free);
   `v4k` mirrors it. This pack documents the ar9287 path (the audited file's
   call site); the v14/v4k twins should get the same `fail:` label.

## Trigger / threat model

Untrusted-EEPROM / hostile-hardware (physical access or resold/reprogrammed
card): any of the three failures is trivially produced by EEPROM content
(checksum mismatch being the easiest — the attacker recomputes or corrupts
it). Each attach attempt with such a card leaks ~1 KB permanently (M_ATH_HAL
kernel heap, no reference, never freed). Hotplug insert/remove cycles repeat
the leak without bound. No UAF, no corruption — a slow, permanent kernel
memory-exhaustion hygiene bug. Severity Low.

## Why no runtime PoC (untested, family precedent DF-4793/DF-4799/DF-4548)

The leak requires an AR9287 card whose EEPROM reads fail partway or fails
checksum/version — the QEMU audit guest has no Atheros NIC, so
`ar9287Attach` is never reached. The static ownership trace above is
complete and has no gaps (allocation → error return → caller unwind →
detach macro → nothing frees `ee`).

## Fix

`fail:` label freeing `ee` before each post-malloc error return — see
`fix.diff` (git-apply-able, verified with `git apply --check`). Not
guest-build-validated (no reason to build a kernel for a change whose
trigger hardware is absent; change is mechanical).

## 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.