Re: [PATCH] wifi: libipw: reject TKIP frames without a full MIC

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2026-09-08 at 17:27 +0900, Daehyeon Ko wrote:
> libipw_tkip_decrypt() accepts a frame containing the TKIP header and a
> valid encrypted ICV even when the plaintext MSDU is shorter than the
> eight-byte Michael MIC.  After it removes the header and ICV,
> libipw_michael_mic_verify() subtracts the missing MIC from skb->len.
> 
> skb->len is unsigned, so a zero-byte plaintext makes
> 
>         skb->len - 8 - hdr_len
> 
> wrap to 4294967288.  michael_mic() then attempts 1073741822 four-byte
> reads starting at the end of the 802.11 header.  Generic KASAN reports a
> slab-out-of-bounds read once the loop leaves the skb allocation.
> 
> The ipw2100 and ipw2200 receive paths call this from a tasklet while
> holding spin_lock_irqsave(), so the OOB access can panic the kernel or
> stall a CPU with local interrupts disabled.
> 
> The trigger requires an affected IPW device using host TKIP
> verification, an active TKIP key, and a sender able to construct a
> non-replayed frame with a valid encrypted ICV.  This conservatively means
> a malicious AP or a peer holding the same TKIP key.
> 
> Require the full MIC before entering the verifier.  A valid-MIC control
> continues to pass.  A zero-payload frame with a valid encrypted ICV is
> dropped without a KASAN report in three fresh boots through libipw_rx().
> 
> The KASAN reproduction uses a white-box module and the registered TKIP
> crypto operations.  I do not have the hardware, so this has not been
> tested over the air.
> 
> The initial candidate was supplied for validation.  AI-assisted tooling
> traced the source and receive paths, prepared the reproducer and fix, and
> ran the build and runtime checks.

Bla bla bla. Please rewrite the commit message.

> +++ b/drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c
> @@ -476,7 +476,7 @@ static int libipw_michael_mic_verify(struct sk_buff *skb, int keyidx,
>  	struct libipw_tkip_data *tkey = priv;
>  	u8 mic[8];
>  
> -	if (!tkey->key_set)
> +	if (!tkey->key_set || skb->len < hdr_len + 8)
>  		return -1;

Why hardcode 8?

johannes