The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Tianchu Chen" <tianchu.chen@linux.dev>
To: "Greg KH" <gregkh@linuxfoundation.org>
Cc: hansg@kernel.org, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: rtl8723bs: fix protected RX frame validation in decrypt path
Date: Wed, 19 Aug 2026 15:11:02 +0000	[thread overview]
Message-ID: <fb7186bc58696dc2117139adef454d674c705ef7@linux.dev> (raw)
In-Reply-To: <2026081946-trolling-handrail-ecac@gregkh>

August 19, 2026 at 10:45 PM, "Greg KH" <gregkh@linuxfoundation.org mailto:gregkh@linuxfoundation.org?to=%22Greg%20KH%22%20%3Cgregkh%40linuxfoundation.org%3E > wrote:


> 
> On Wed, Aug 19, 2026 at 02:22:47PM +0000, Tianchu Chen wrote:
> 
> > 
> > From: Tianchu Chen <flynnnchen@tencent.com>
> >  
> >  The RX software decrypt path mishandles crafted protected frames from a
> >  malicious AP in two ways:
> >  
> >  1) decryptor() never checks that a protected frame is long enough to
> >  hold the 802.11 header plus the per-cipher trailer(IV, ICV/MIC).
> >  
> >  Implementations like rtw_wep_decrypt() and rtw_aes_decrypt() all compute
> >  length = hdr.len - hdrlen - iv_len. and a shorter frame underflows the 
> >  unsigned subtraction, turning into OOB reads/writes.
> >  
> >  Reject such frames in decryptor() before touching the IV.
> >  
> >  2) validate_80211w_mgmt() uses the skb before checking whether
> >  decryptor() returned NULL. On decrypt failure the skb has been freed
> >  before being used.
> >  
> >  Bail out immediately when decryptor() fails.
> >  
> >  Discovered by Atuin - Automated Vulnerability Discovery Engine.
> >  
> >  Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> >  Cc: stable@vger.kernel.org
> >  Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
> > 
> No assisted-by: line?
> 
> And you have read this:
>  https://lore.kernel.org/all/2026080354-skater-urgent-31b2@gregkh
> right?


Thanks for pointing out, I have not read this before.

Assisted-by: kimi-code:kimi-k3

> So did you test this on the real hardware?

Unfortunately I have no real hardware.

      reply	other threads:[~2026-08-19 15:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19 14:22 [PATCH] staging: rtl8723bs: fix protected RX frame validation in decrypt path Tianchu Chen
2026-08-19 14:45 ` Greg KH
2026-08-19 15:11   ` Tianchu Chen [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=fb7186bc58696dc2117139adef454d674c705ef7@linux.dev \
    --to=tianchu.chen@linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=hansg@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    /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