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: <CADm8Te=TRTgCaRm0Ebgos8n0qZ+7HJ7Q80Ck+-d8NtCMdAb1Zw@mail.gmail.com>
Date: Thu, 8 Jan 2026 21:28:30 +0800
From: Tuo Li <islituo@...il.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: Stanislaw Gruszka <stf_xl@...pl>, 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()

Hi Johannes,

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.
>
> johannes

Thanks for the clarification.

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.

If you believe this situation cannot occur in practice and the additional
check is unnecessary, I'm fine with dropping this change.

Thanks for taking the time to review this.

Best regards,
Tuo