All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: Bitterblue Smith <rtl8821cerfe2@gmail.com>,
	Tristan Madani <tristmd@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: [PATCH v2] wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer
Date: Mon, 20 Apr 2026 05:31:02 +0000	[thread overview]
Message-ID: <e4f18297feda4056bb461b6b2516b27c@realtek.com> (raw)
In-Reply-To: <090b3c83-e3d5-4c8d-bd46-aaff692de529@gmail.com>

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> 
> On 16/04/2026 01:24, Tristan Madani wrote:
> > From: Tristan Madani <tristan@talencesecurity.com>
> >
> > In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit
> > descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both
> > firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478),
> > causing an out-of-bounds read from the pre-allocated DMA buffer when
> > skb_put_data copies new_len bytes. The USB transport already validates
> > this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the
> > PCIe path does not.
> >
> > Add a check that new_len does not exceed the DMA buffer size.
> >
> > Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
> > Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> > ---
> > Note: v2 resubmission -- original sent via Gmail had HTML rendering
> > issues. This version uses git send-email for plain-text formatting.
> >
> > Changes in v2:
> >   - v2: clarify field widths and maximum new_len derivation in commit
> >     message, per Ping-Ke Shih's feedback.
> >
> > drivers/net/wireless/realtek/rtw88/pci.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
> > index XXXXXXX..XXXXXXX 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -1078,6 +1078,11 @@ static int rtw_pci_rx_napi(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci,
> >               new_len = pkt_stat.pkt_len + pkt_offset;
> > +             if (new_len > RTK_PCI_RX_BUF_SIZE) {

Since this is data (hot) path, I'd prefer unlikely(new_len > RTK_PCI_RX_BUF_SIZE).

> > +                     rtw_dbg(rtwdev, RTW_DBG_RX,
> > +                             "oversized RX packet: %u\n", new_len);
> > +                     goto next_rp;
> > +             }
> >               new = dev_alloc_skb(new_len);
> >               if (WARN_ONCE(!new, "rx routine starvation\n"))
> >                       goto next_rp;
> >
> >
> 
> I'm working on a patch which will implement the same validation
> in rtw_rx_query_rx_desc(), along with two other checks. I got a
> report about too short packets from RTL8814AU, so USB devices
> can also benefit from checking pkt_len. It will make this patch
> redundant.

Bitterblue, if you can take the change of this patch into your
patch, I'd skip this patch. Please let me know your thought.

> 
> Well, kind of. Maybe RTK_PCI_RX_BUF_SIZE is too small? 11454 + 24
> doesn't take into account the PHY info size.

In rtw_pci_sync_rx_desc_device(), driver does
    buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);

This is to tell hardware the size of RX DMA buffer. I think hardware
can't DMA data over this size.

Ping-Ke


  reply	other threads:[~2026-04-20  5:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-15 22:24 [PATCH v2] wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer Tristan Madani
2026-04-17 15:14 ` Bitterblue Smith
2026-04-20  5:31   ` Ping-Ke Shih [this message]
2026-04-20 22:22     ` Bitterblue Smith
2026-04-21  1:38       ` Ping-Ke Shih

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=e4f18297feda4056bb461b6b2516b27c@realtek.com \
    --to=pkshih@realtek.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rtl8821cerfe2@gmail.com \
    --cc=tristmd@gmail.com \
    /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.