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

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

[Daehyeon Ko]

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.

Fixes: b453872c35cf ("[NET] ieee80211 subsystem")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
---
A tested source reproducer and full serial logs are available privately
to the maintainers on request.  They are not included because this
finding was validated with AI assistance, as required by
Documentation/process/security-bugs.rst.

The source-equivalent one-line change was apply-checked on every current
supported stable tag from v7.2.4 through v5.10.269.  v6.18 and older
require context or path-adjusted backports because libipw was moved and
the Michael helper was later changed.

 drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c b/drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c
index 24bb28ab7a49b..1fe543ea9dd26 100644
--- a/drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c
+++ 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;
 
 	michael_mic(&tkey->key[24], (struct ieee80211_hdr *)skb->data,

base-commit: da2ca406f45a6e21760243152ed8d2e8e72915c2
-- 
2.55.0

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

[Johannes Berg]

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