linux-kernel - Re: [PATCH v2] wifi: iwlegacy: 3945-rs: fix possible null-pointer dereferences in il3945_rs_get

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260108163355.GA38716@wp.pl>
Date: Thu, 8 Jan 2026 17:33:55 +0100
From: Stanislaw Gruszka <stf_xl@...pl>
To: Tuo Li <islituo@...il.com>
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 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