lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADm8TemGjSooBLR+0+rk+izhZcSSHruSjTeMFeH9-KpqZGd+1Q@mail.gmail.com>
Date: Fri, 9 Jan 2026 10:42:25 +0800
From: Tuo Li <islituo@...il.com>
To: Stanislaw Gruszka <stf_xl@...pl>
Cc: Johannes Berg <johannes@...solutions.net>, linux-wireless@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] wifi: iwlegacy: 3945-rs: fix possible null-pointer
 dereferences in il3945_rs_get_rate()

On Fri, Jan 9, 2026 at 12:33 AM Stanislaw Gruszka <stf_xl@...pl> wrote:
>
> On Thu, Jan 08, 2026 at 09:28:30PM +0800, Tuo Li wrote:
> > On Thu, Jan 8, 2026 at 8:02 PM Johannes Berg <johannes@...solutions.net> wrote:
> > > I can apply this if you want, but for the record,
> > >
> > > > > +++ b/drivers/net/wireless/intel/iwlegacy/3945-rs.c
> > > > > @@ -626,10 +626,15 @@ il3945_rs_get_rate(void *il_r, struct ieee80211_sta *sta, void *il_sta,
> > > > >
> > > > >     D_RATE("enter\n");
> > > > >
> > > > > +   if (!il_sta) {
> > > > > +           D_RATE("leave: No STA il data to update!\n");
> > > > > +           return;
> > > > > +   }
> > > > > +
> > >
> > > I don't see how this would be possible. _Maybe_ the other one, but I
> > > can't figure out any scenario in mac80211 where it could happen either.
>
> Regarding checking the rs_sta->il, we can get rid of the ->il
> backpointer, it's only used for printing debug messages in a few
> functions. I don't think person needing to debug 3945 rate scaling
> algorithm exist nowadays :-)
>
> I'll send patch for that.
>
> > I don't have a concrete mac80211 execution path that would result in
> > il_sta being NULL here either. This issue was reported by a static
> > analysis tool, and after reviewing the code I noticed that the handling is
> > not consistent with il3945_rs_tx_status(), which is why I submitted this
> > patch to add a defensive check.
>
> IMO is ok to have defensive checks (in reasonable amount :-)
>
> They can be marked with WARN_ON_ONCE like this:
>
>    if (WARN_ON_ONCE(!il_sta))
>         return
>
> that would clearly indicate the check is for 'not possible' scenario.
>
> Regards
> Stanislaw
>
>

Hi Stanislaw,

Thanks for your reply.

I will add a defensive WARN_ON_ONCE() at the beginning of
il3945_rs_get_rate() to catch this unexpected condition, and will submit a
v3 patch accordingly.

Best regards,
Tuo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ