All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luka Gejak" <luka.gejak@linux.dev>
To: "Delene Tchio Romuald" <delenetchior1@gmail.com>,
	<gregkh@linuxfoundation.org>
Cc: "Ethan Tidmore" <ethantidmore06@gmail.com>,
	"Sam Daly" <sam@samdaly.ie>, <linux-staging@lists.linux.dev>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 5/5] staging: rtl8723bs: fix negative length in WEP decryption
Date: Wed, 15 Apr 2026 15:57:41 +0200	[thread overview]
Message-ID: <DHTS4Y8QKDSA.28VLQAVTLYHIJ@linux.dev> (raw)
In-Reply-To: <20260405101548.124829-6-delenetchior1@gmail.com>

On Sun Apr 5, 2026 at 12:15 PM CEST, Delene Tchio Romuald wrote:
> In rtw_wep_decrypt(), length is declared as signed int and computed as:
>
>   length = len - hdrlen - iv_len;
>
> If the received frame is shorter than the combined header and IV
> lengths, length becomes negative. It is then passed to arc4_crypt()
> which takes a u32 parameter, causing the negative value to be
> implicitly cast to a very large unsigned value (e.g., -8 becomes
> 4294967288). This results in a massive out-of-bounds read and write
> on the heap via arc4_crypt(), and a similar overflow at the
> subsequent crc32_le() call using length - 4.
>
> Add a minimum frame length check before the subtraction to ensure
> length is always positive.
>
> Found by reviewing memory operations in the driver.
> Not tested on hardware.
>
> Signed-off-by: Delene Tchio Romuald <delenetchior1@gmail.com>
> ---
> v3:
>  - Rebased on staging-next
>  - Sent as numbered series with proper Cc from get_maintainer.pl
>
>  drivers/staging/rtl8723bs/core/rtw_security.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_security.c b/drivers/staging/rtl8723bs/core/rtw_security.c
> index a00504ff29109..f3bc2240749a4 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_security.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_security.c
> @@ -113,6 +113,12 @@ void rtw_wep_decrypt(struct adapter  *padapter, u8 *precvframe)
>  		memcpy(&wepkey[0], iv, 3);
>  		/* memcpy(&wepkey[3], &psecuritypriv->dot11DefKey[psecuritypriv->dot11PrivacyKeyIndex].skey[0], keylength); */
>  		memcpy(&wepkey[3], &psecuritypriv->dot11DefKey[keyindex].skey[0], keylength);
> +
> +		/* Ensure the frame is long enough for WEP decryption */
> +		if (((union recv_frame *)precvframe)->u.hdr.len <=
> +		    prxattrib->hdrlen + prxattrib->iv_len)
> +			return;
> +
>  		length = ((union recv_frame *)precvframe)->u.hdr.len - prxattrib->hdrlen - prxattrib->iv_len;
>  
>  		payload = pframe + prxattrib->iv_len + prxattrib->hdrlen;

LGTM.

Reviewed-by: Luka Gejak <luka.gejak@linux.dev>

Best regards,
Luka Gejak

      reply	other threads:[~2026-04-15 13:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-05 10:15 [PATCH v3 0/5] staging: rtl8723bs: fix multiple missing bounds checks Delene Tchio Romuald
2026-04-05 10:15 ` [PATCH v3 1/5] staging: rtl8723bs: fix heap buffer overflow in recvframe_defrag() Delene Tchio Romuald
2026-04-15 13:56   ` Luka Gejak
2026-04-15 15:24   ` Dan Carpenter
2026-04-15 16:10     ` Dan Carpenter
2026-04-05 10:15 ` [PATCH v3 2/5] staging: rtl8723bs: fix integer underflow in TKIP MIC verification Delene Tchio Romuald
2026-04-15 13:56   ` Luka Gejak
2026-04-05 10:15 ` [PATCH v3 3/5] staging: rtl8723bs: fix out-of-bounds read in portctrl() Delene Tchio Romuald
2026-04-15 13:57   ` Luka Gejak
2026-04-05 10:15 ` [PATCH v3 4/5] staging: rtl8723bs: fix out-of-bounds reads in IE parsing functions Delene Tchio Romuald
2026-04-15 13:57   ` Luka Gejak
2026-04-05 10:15 ` [PATCH v3 5/5] staging: rtl8723bs: fix negative length in WEP decryption Delene Tchio Romuald
2026-04-15 13:57   ` 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=DHTS4Y8QKDSA.28VLQAVTLYHIJ@linux.dev \
    --to=luka.gejak@linux.dev \
    --cc=delenetchior1@gmail.com \
    --cc=ethantidmore06@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=sam@samdaly.ie \
    /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.