wifi: mac80211: make n_channels updated absolutely before accessing channels[]

xu.xin16@zte.com.cn posted 1 patch 2 months, 3 weeks ago
net/mac80211/scan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
wifi: mac80211: make n_channels updated absolutely before accessing channels[]
Posted by xu.xin16@zte.com.cn 2 months, 3 weeks ago
From: xu xin <xu.xin16@zte.com.cn>

The commit 2663d0462eb3 ("wifi: mac80211: Avoid address calculations via out of
bounds array indexing") said that req->n_channels must be set before
req->channels[] can be used. But there&apos;s still the case that req.channels
accessing was prior to n_channels++.

This does not fix any visible bug, just making n_channels updated before
accessing channels[] absolutely, to avoid potential UBSAN out of indexing
warning.

Fixes: 2663d0462eb3 ("wifi: mac80211: Avoid address calculations via out of bounds array indexing")
Signed-off-by: xu xin <xu.xin16@zte.com.cn>
---
net/mac80211/scan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 5ef315ed3b0f..86bd85ac36be 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -406,7 +406,9 @@ static bool ieee80211_prep_hw_scan(struct ieee80211_sub_if_data *sdata)
 				if (req->channels[i]->band !=
 				local->hw_scan_band)
 					continue;
-				local->hw_scan_req->req.channels[(*n_chans)++] =
+				(*n_chans)++;
+				/* Use *n_chans - 1 to access the index that was valid before incrementing */
+				local->hw_scan_req->req.channels[*n_chans - 1] =
 							req->channels[i];

 				bands_used |= BIT(req->channels[i]->band);
--
2.25.1
Re: wifi: mac80211: make n_channels updated absolutely before accessing channels[]
Posted by Johannes Berg 2 months, 3 weeks ago
On Wed, 2025-11-12 at 16:37 +0800, xu.xin16@zte.com.cn wrote:
> From: xu xin <xu.xin16@zte.com.cn>
> 
> The commit 2663d0462eb3 ("wifi: mac80211: Avoid address calculations via out of
> bounds array indexing") said that req->n_channels must be set before
> req->channels[] can be used. But there&apos;s still the case that req.channels
> accessing was prior to n_channels++.
> 
> This does not fix any visible bug, just making n_channels updated before
> accessing channels[] absolutely, to avoid potential UBSAN out of indexing
> warning.

I reverted the annotations, so this isn't necessary.

johannes
Re: wifi: mac80211: make n_channels updated absolutely before accessing channels[]
Posted by xu.xin16@zte.com.cn 2 months, 3 weeks ago
> > From: xu xin <xu.xin16@zte.com.cn>
> > 
> > The commit 2663d0462eb3 ("wifi: mac80211: Avoid address calculations via out of
> > bounds array indexing") said that req->n_channels must be set before
> > req->channels[] can be used. But there&apos;s still the case that req.channels
> > accessing was prior to n_channels++.
> > 
> > This does not fix any visible bug, just making n_channels updated before
> > accessing channels[] absolutely, to avoid potential UBSAN out of indexing
> > warning.
> 
> I reverted the annotations, so this isn't necessary.

Excuse me, what is the annotations you reverted ? Maybe I missed somthing.
Re: wifi: mac80211: make n_channels updated absolutely before accessing channels[]
Posted by Johannes Berg 2 months, 3 weeks ago
On Wed, 2025-11-12 at 16:50 +0800, xu.xin16@zte.com.cn wrote:
> > > From: xu xin <xu.xin16@zte.com.cn>
> > > 
> > > The commit 2663d0462eb3 ("wifi: mac80211: Avoid address calculations via out of
> > > bounds array indexing") said that req->n_channels must be set before
> > > req->channels[] can be used. But there&apos;s still the case that req.channels
> > > accessing was prior to n_channels++.
> > > 
> > > This does not fix any visible bug, just making n_channels updated before
> > > accessing channels[] absolutely, to avoid potential UBSAN out of indexing
> > > warning.
> > 
> > I reverted the annotations, so this isn't necessary.
> 
> Excuse me, what is the annotations you reverted ? Maybe I missed somthing.

You missed multiple things, for example the fact that your changes do
nothing.

Please, everyone, don't submit changes when you don't understand _both_
the original code (at least mostly) and your "own" changes.

Otherwise we'll just think you used an LLM to cause us work and never
take you seriously again.

johannes