Linux wireless drivers development
 help / color / mirror / Atom feed
From: Maxim Skokov <skokovmaksimevg@gmail.com>
To: tristan@talencesecurity.com, tristmd@gmail.com
Cc: pkshih@realtek.com, linux-wireless@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] wifi: rtw89: fix OOB read in __rtw89_wow_parse_akm()
Date: Sun,  6 Sep 2026 02:43:03 +0300	[thread overview]
Message-ID: <20260905234309.6922-1-skokovmaksimevg@gmail.com> (raw)
In-Reply-To: <20260830143154.1751910-2-tristmd@gmail.com>

On Sun, Aug 30, 2026 at 02:31:53PM +0000, Tristan Madani wrote:
> skb->len is the total frame length, not the length of the IE portion.
> The IEs in an association request start at offset 28 (24-byte header +
> 4-byte fixed fields), so the correct IE length is skb->len minus that
> offset.  Passing the full frame length causes cfg80211_find_ie() to walk
> up to 28 bytes past the end of the skb data buffer, triggering a
> slab-out-of-bounds read.

The length passed to cfg80211_find_ie() is indeed wrong and the fix looks
correct to me.  I did try to reproduce the reported slab-out-of-bounds
though, and I don't think it is reachable.  If I'm wrong about this,
I'd be glad to be corrected.

cfg80211_find_ie() walks the elements via for_each_element(), which is
bounded by _data + _datalen and never dereferences past it.  With
ies = skb->data + 28 and len = skb->len, the highest byte the walk can
touch is skb->data + 28 + skb->len - 1, i.e. exactly 28 bytes past
skb_tail_pointer(), as you describe.

What follows skb_tail_pointer(), however, is the skb tailroom and then
struct skb_shared_info, and both live inside the same allocation.
sizeof(struct skb_shared_info) is 320 bytes on x86_64, so even with zero
tailroom the 28-byte overread stays within the object and KASAN has
nothing to report.

Measured on RTL8851BE (rtw89_8851be) with a kprobe on
__rtw89_wow_parse_akm(), on a real association request:

    skb->len   tailroom   overread   slack to end of allocation
    160        1552       28         1872

So the defect is a read of uninitialised memory inside the skb rather
than an out-of-bounds access -- KMSAN territory, not KASAN.  The
practical consequence is that on a network with no RSN IE (an open BSS,
where mac80211 emits no RSN element at all), the walk continues into the
tailroom and may match a bogus element with id 48, after which
rtw_wow->akm is set from garbage.

That is still worth fixing, but it may be worth rewording the commit
message, since the "slab-out-of-bounds" wording is what justifies the
Cc: stable here.  The same reasoning applies to patch 1/2.

One more thing in the same function, which this patch does not address:

	rsn_ie = (struct rtw89_rsn_ie *)rsn;
	rtw_wow->akm = rsn_ie->akm_cipher_suite.type;

struct rtw89_rsn_ie is 20 bytes and akm_cipher_suite.type sits at offset
19, but cfg80211_find_ie() only validates the element header.  A minimal
RSN element with datalen = 2 (version only) makes that read land 15
bytes past the end of the element, and with the length fix applied it can
still reach past the end of the frame when the element sits at the tail.
Checking rsn[1] before the cast would close that too.

Thanks,
Maxim

  reply	other threads:[~2026-09-05 23:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-30 14:31 [PATCH wireless 1/2] wifi: rtw89: fix OOB read in rtw89_core_cancel_6ghz_probe_tx() Tristan Madani
2026-08-30 14:31 ` [PATCH wireless 2/2] wifi: rtw89: fix OOB read in __rtw89_wow_parse_akm() Tristan Madani
2026-09-05 23:43   ` Maxim Skokov [this message]
2026-09-07  2:40   ` Ping-Ke Shih
2026-09-07  2:31 ` [PATCH wireless 1/2] wifi: rtw89: fix OOB read in rtw89_core_cancel_6ghz_probe_tx() 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=20260905234309.6922-1-skokovmaksimevg@gmail.com \
    --to=skokovmaksimevg@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pkshih@realtek.com \
    --cc=tristan@talencesecurity.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox