From: Dan Carpenter <dan.carpenter@linaro.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Lin YuChen <starpt.official@gmail.com>,
straube.linux@gmail.com, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()
Date: Sat, 21 Mar 2026 10:57:57 +0300 [thread overview]
Message-ID: <ab5Phf6yF9Tw9-1W@stanley.mountain> (raw)
In-Reply-To: <2026032035-opulently-cupbearer-820b@gregkh>
On Fri, Mar 20, 2026 at 06:29:13PM +0100, Greg KH wrote:
> On Sat, Mar 21, 2026 at 01:25:02AM +0800, Lin YuChen wrote:
> > Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using
> > uninitialized data.
> >
> > Smatch warns that only 6 bytes are copied to this 8-byte (u64)
> > variable, leaving the last two bytes uninitialized:
> >
> > drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify()
> > warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes)
> >
> > Initializing the variable at the start of the function fixes this
> > warning and ensures predictable behavior.
>
> Which makes me wonder how this ever worked at all, if random data was in
> those 2 bytes.
These days, everyone sane zeroes their stack variables, but this driver
is older than the zeroing code so it's a puzzling thing.
I could imagine a couple different ways that the code might be able to
work even with uninitialized data... It wouldn't surprise me if the
check for:
/* BIP packet number should bigger than previous BIP packet */
is some kind of work around for bug?
regards,
dan carpenter
next prev parent reply other threads:[~2026-03-21 7:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 17:25 [PATCH v2] staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() Lin YuChen
2026-03-20 17:29 ` Greg KH
2026-03-21 7:57 ` Dan Carpenter [this message]
2026-03-23 10:38 ` YuChen Lin
2026-03-21 7:47 ` Dan Carpenter
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=ab5Phf6yF9Tw9-1W@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=starpt.official@gmail.com \
--cc=straube.linux@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.