Summary

radiotap_offset() iterates 'for (i = 0; i < IEEE80211_RADIOTAP_EXT; i++)' (i <= 30) but items[] has only 20 designated entries. Any present bit in 20..30 (AMPDU_STATUS=20, VENDOREXT=30 defined but absent from items[]) makes items[i] an OOB read of adjacent static rodata; garbage align/width then feed the offset arithmetic with size_t truncation into the int off, which could in principle drive off negative and pass the 'off + width > it_len' check, returning a bad offset that chan_change's set_channel would write through. NOT reachable through current callers: attachv only invokes radiotap_offset with item in {CHANNEL(3), XCHANNEL(18)}, both set bits so the ascending walk returns at i==item <= 18; all in-tree driver masks verified to set only bits <= 19. A driver-misuse hazard: any out-of-tree or future driver setting AMPDU_STATUS/VENDOREXT alongside CHANNEL gets an OOB rodata read at attach. Bits 14-17 set by a driver silently disable channel tracking (functional loss only). Fix: clamp the walk to nitems(items) (+ optionally add the missing entries). [VERIFIED pass2: loop bound 31 vs about-20-entry items confirmed unreachable through current callers bits le 19; nitems bound compiled]