# DF-3832 — `trm_eepromBuf[unit]` indexed by adapter unit with no TRM_MAX_ADAPTER_NUM bound — 128-byte OOB read+write of adjacent kernel globals at attach

- File: `sys/dev/disk/trm/trm.c` (pass 2)
- Class: CWE-787 out-of-bounds write (static global array), boot/attach-time
- Severity: Low (requires 5 or more Tekram DC395 adapters in one machine — physical access)

## Build / Run / Expected
Hardware-gated. On a machine with five Tekram DC395U/U2W PCI adapters, the 5th `trm_attach`
(unit = 4) reads and writes `trm_eepromBuf[4]` — one entry past the end of the 4-entry global
array — corrupting whatever linker-placed data follows it in .bss.

## Root cause
- `NVRAMTYPE trm_eepromBuf[TRM_MAX_ADAPTER_NUM];` — trm.c:212, `TRM_MAX_ADAPTER_NUM = 4`
  (trm.h:90). Each entry is 128 bytes (NVRAM_STRUC, trm.h:937-959).
- `trm_attach` (trm.c:3549): `int unit = device_get_unit(dev);` — unbounded devclass unit.
- `trm_init(unit)` → `trm_check_eeprom(&trm_eepromBuf[unit], pACB)` — trm.c:3480 — and
  `trm_initACB`/`trm_initDCB` use `&trm_eepromBuf[unit]` again (trm.c:3066, 2925, 1112).
  None of these sites checks `unit < TRM_MAX_ADAPTER_NUM`.
- Inside `trm_check_eeprom`, `NVRAM_trm_read_all` writes **all 128 bytes** read from the
  SEEPROM through `*bpEeprom = NVRAM_trm_get_data(...)` (trm.c:3181-3182) — so unit 4 writes
  128 bytes past the array; the checksum-defaults path (trm.c:3289-3321) writes even more via
  the already-reported u_long bug DF-2525.

Distinct from DF-2525 (which is the u_long-vs-4-byte-schema overflow *within* the struct even
for unit 0): this finding is the *index* bound — the wrong struct is selected out of bounds
even with well-typed accesses.