From: "Luka Gejak" <luka.gejak@linux.dev>
To: "Huihui Huang" <hhhuang@smu.edu.sg>, linux-wireless@vger.kernel.org
Cc: "Huihui Huang" <hhhuang@smu.edu.sg>,
"Ping-Ke Shih" <pkshih@realtek.com>,
stable@vger.kernel.org
Subject: Re: [PATCH rtw-next] wifi: rtw88: drop C2H packets shorter than the C2H header
Date: Fri, 30 Oct 2026 14:36:58 +0000 [thread overview]
Message-ID: <1c6b269275da44f667b6cab73968fee752860eda@linux.dev> (raw)
In-Reply-To: <20261029170017.832708-1-hhhuang@smu.edu.sg>
Hi Huihui,
I have two comments below, nothing major.
October 29, 2026 at 6:00 PM, "Huihui Huang" <hhhuang@smu.edu.sg> wrote:
> diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
> index 945fedcd375b..2e37c304cde0 100644
> --- a/drivers/net/wireless/realtek/rtw88/fw.c
> +++ b/drivers/net/wireless/realtek/rtw88/fw.c
> @@ -353,6 +353,12 @@ void rtw_fw_c2h_cmd_rx_irqsafe(struct rtw_dev *rtwdev, u32 pkt_offset,
> struct rtw_c2h_cmd *c2h;
> u8 len;
>
> + if (unlikely(skb->len < pkt_offset + sizeof(*c2h))) {
> + rtw_dbg(rtwdev, RTW_DBG_FW, "C2H too short: %u\n", skb->len);
Small thing, skb->len here still includes the RX descriptor, so the value
printed is not the C2H length. Maybe print skb->len - pkt_offset instead,
so it shows how much of the C2H actually arrived?
> + dev_kfree_skb_any(skb);
> + return;
> + }
> +
> c2h = (struct rtw_c2h_cmd *)(skb->data + pkt_offset);
> len = skb->len - pkt_offset - 2;
This takes care of the header, but as far as I can see a C2H with only
the two header bytes still gets through, with len 0. Most handlers read
their payload without looking at len, e.g. right below in this function:
case C2H_SCAN_RESULT:
complete(&rtwdev->fw_scan_density);
rtw_fw_scan_result(rtwdev, c2h->payload, len);
and rtw_fw_scan_result() reads payload[0] unconditionally. So if I read
it right, skb->len == pkt_offset + 2 ends the same way as your test cases
1 and 2: scan_density is taken from the byte right after skb->len.
rtw_coex_info_response(), rtw_fw_c2h_cmd_handle_ext() and
rtw_tx_report_handle() seem to have the same problem. They read fixed
offsets in the payload and don't get len at all.
Would you be willing to add length checks to those handlers too? Maybe
as a separate patch, so this one stays small for stable.
Best regards,
Luka Gejak
prev parent reply other threads:[~2026-10-30 14:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 17:00 [PATCH rtw-next] wifi: rtw88: drop C2H packets shorter than the C2H header Huihui Huang
2026-10-30 14:36 ` Luka Gejak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1c6b269275da44f667b6cab73968fee752860eda@linux.dev \
--to=luka.gejak@linux.dev \
--cc=hhhuang@smu.edu.sg \
--cc=linux-wireless@vger.kernel.org \
--cc=pkshih@realtek.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.