Re: [PATCH] wifi: ar5523: fix integer underflow in ar5523_data_rx_cb()
From: Jeff Johnson
Date: Thu Jul 16 2026 - 18:16:02 EST
On 11/3/2025 11:55 AM, pip-izony wrote:
> From: Seungjin Bae <eeodqql09@xxxxxxxxx>
>
> In ar5523_data_rx_cb(), the `rxlen` variable is derived from desc->len,
> which is provided by the USB device.
>
> The function checks for an upper bound (rxlen > ar->rxbufsz) and for a
> zero value (!rxlen), but it fails to check for a proper lower bound
> against the size of the descriptor.
>
> If a malicious device provides an `rxlen` value that is positive
> but smaller than sizeof(struct ar5523_rx_desc), the subtraction in
> the call to skb_put() will result in an integer underflow.
>
> This passes a very large unsigned value to skb_put(), which then
> triggers a kernel panic upon detecting the potential buffer overflow.
>
> Fix this by adding a check to ensure `rxlen` is at least
> sizeof(struct ar5523_rx_desc) before performing the substraction.
>
> Fixes: b7d572e1871df ("ar5523: Add new driver")
> Signed-off-by: Seungjin Bae <eeodqql09@xxxxxxxxx>
> ---
> drivers/net/wireless/ath/ar5523/ar5523.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c
> index 1230e6278f23..dfaccf241560 100644
> --- a/drivers/net/wireless/ath/ar5523/ar5523.c
> +++ b/drivers/net/wireless/ath/ar5523/ar5523.c
> @@ -589,6 +589,12 @@ static void ar5523_data_rx_cb(struct urb *urb)
> goto skip;
> }
>
> + if (rxlen < sizeof(struct ar5523_rx_desc)) {
> + ar5523_dbg(ar, "RX: Bad descriptor (len=%d is too small)\n",
> + rxlen);
> + goto skip;
> + }
> +
> skb_reserve(data->skb, sizeof(*chunk));
> skb_put(data->skb, rxlen - sizeof(struct ar5523_rx_desc));
>
Since this is an orphaned driver, this patch has been sitting in my patchwork
queue for a very long time. Today I decided to take a look.
The patch does address the issue mentioned, but really doesn't completely
address the crux of the issue. I believe there should be a fixed correlation
between the rxlen and the usblen. I posed the following question to my review
agent:
given that the usblen should account for the ar5523_chunk header, the payload,
and the ar5523_rx_desc, shouldn't the rxlen always be the same as the usblen -
sizeof(ar5523_chunk)?
And my agent agreed:
Yes, that's exactly right. Looking at the struct comment "msg length including
header" for desc->len and the frame layout:
[ar5523_chunk (4B)] [802.11 payload] [ar5523_rx_desc]
←──────────────────── usblen ──────────────────────→
The invariant should be:
rxlen == usblen - sizeof(ar5523_chunk)
Because rxlen covers [802.11 payload] + [ar5523_rx_desc], and usblen covers
everything including the chunk header.
The code never cross-validates them. It independently bounds-checks usblen
(via AR5523_MIN_RXBUFSZ) and rxlen (upper bound vs rxbufsz, lower bound added
by the patch), but if a malicious device provides rxlen > usblen -
sizeof(ar5523_chunk), then:
skb_put(data->skb, rxlen - sizeof(struct ar5523_rx_desc));
...would expose bytes beyond the actual 802.11 payload — potentially biting
into the ar5523_rx_desc trailer bytes, or uninitialized skb tail space up to
rxbufsz, and pass that garbage to ieee80211_rx_irqsafe().
The existing upper bound check rxlen > ar->rxbufsz prevents a skb_put
overflow (since the skb is allocated with rxbufsz), but it's far too loose.
The right check would be:
if (rxlen != usblen - sizeof(struct ar5523_chunk))
goto skip;
Or at minimum a strict upper bound:
if (rxlen > usblen - sizeof(struct ar5523_chunk))
goto skip;
So the patch fixes the underflow but misses this inconsistency between rxlen
and usblen that could allow overreading valid-but-wrong data within the skb
buffer.
So please consider this analysis and propose a v2
/jeff