Regression on big-endian: ff5248a8e91e drops needed le_to_host16()

[Jouni Malinen]

On Tue, Jun 09, 2026 at 03:12:55PM +0200, Alexander Wilhelm wrote:
> ff5248a8e91e ("nl80211: Fix HE 6 GHz capability fetching on big-endian
> CPUs") breaks 6 GHz AP on BE hosts (PowerPC e500mc, ath12k/QCN9274):
> 
>     The driver does not support the configured HE 6 GHz Max MPDU length

Thanks for reporting this.

> The kernel sends NL80211_BAND_IFTYPE_ATTR_HE_6GHZ_CAPA as a raw __le16
> (struct ieee80211_he_6ghz_capa { __le16 capa; }, see
> include/linux/ieee80211-he.h and the nla_put() in
> net/wireless/nl80211.c). nla_get_u16() is a host-order load of those
> raw bytes, so on BE the value comes out byte-swapped (0xb832 instead
> of 0x32b8) and the MAX_MPDU bits read as zero.
> 
> The original le_to_host16() was load-bearing on BE and a no-op on LE.
> mac80211 itself treats the field as LE (le16_get_bits() in
> net/mac80211/he.c, util.c). Reverting your commit fixes 6 GHz here
> without affecting LE.
> 
> Did I miss something, or is this a straightforward regression worth
> reverting?

It is a bit more complicated (or confusing) than that, i.e., the
attribute was processed as a u16 attribute when added in hostap.git and
such attributes should data in host byte order and this was indeed what
the mismatch in u16 and le_to_host16() was being reported as an issue in
static analysis. However, you are correct that these two bytes are
indeed in little endian byte order. The kernel code for this seems to be
handling this as binary data instead of a u16 attribute, so instead of
reverting that previous fix, this is now fixed properly to avoid the
mismatch between kernel encoding (binary data that happens to start
with, and for now, consists of, a 16-bit field in little endian byte
order):
https://git.w1.fi/cgit/hostap/commit/?id=00760f77483751a31e222b57b1966ac3757152ea

-- 
Jouni Malinen                                            PGP id EFC895FA