linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: linux-wireless@vger.kernel.org, bjlockie@lockie.ca,
	johannes@sipsolutions.net, nbd@nbd.name
Subject: Re: [PATCH wireless] wifi: mac8021: fix possible oob access in ieee80211_get_rate_duration
Date: Sun, 06 Nov 2022 14:43:03 +0100	[thread overview]
Message-ID: <8735aww654.fsf@toke.dk> (raw)
In-Reply-To: <Y2e3hBYhdUtrMKtm@lore-desk>

Lorenzo Bianconi <lorenzo@kernel.org> writes:

>> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>> 
>> > Fix possible out-of-bound access in ieee80211_get_rate_duration routine
>> > as reported by the following UBSAN report:
>> >
>> > UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47
>> > index 15 is out of range for type 'u16 [12]'
>> > CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic
>> > Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017
>> > Workqueue: mt76 mt76u_tx_status_data [mt76_usb]
>> > Call Trace:
>> >  <TASK>
>> >  show_stack+0x4e/0x61
>> >  dump_stack_lvl+0x4a/0x6f
>> >  dump_stack+0x10/0x18
>> >  ubsan_epilogue+0x9/0x43
>> >  __ubsan_handle_out_of_bounds.cold+0x42/0x47
>> > ieee80211_get_rate_duration.constprop.0+0x22f/0x2a0 [mac80211]
>> >  ? ieee80211_tx_status_ext+0x32e/0x640 [mac80211]
>> >  ieee80211_calc_rx_airtime+0xda/0x120 [mac80211]
>> >  ieee80211_calc_tx_airtime+0xb4/0x100 [mac80211]
>> >  mt76x02_send_tx_status+0x266/0x480 [mt76x02_lib]
>> >  mt76x02_tx_status_data+0x52/0x80 [mt76x02_lib]
>> >  mt76u_tx_status_data+0x67/0xd0 [mt76_usb]
>> >  process_one_work+0x225/0x400
>> >  worker_thread+0x50/0x3e0
>> >  ? process_one_work+0x400/0x400
>> >  kthread+0xe9/0x110
>> >  ? kthread_complete_and_exit+0x20/0x20
>> >  ret_from_fork+0x22/0x30
>> >
>> > Reported-by: bjlockie@lockie.ca
>> > Fixes: db3e1c40cf2f ("mac80211: Import airtime calculation code from mt76")
>> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>> > ---
>> >  net/mac80211/airtime.c | 3 +++
>> >  1 file changed, 3 insertions(+)
>> >
>> > diff --git a/net/mac80211/airtime.c b/net/mac80211/airtime.c
>> > index 2e66598fac79..4ed05988131d 100644
>> > --- a/net/mac80211/airtime.c
>> > +++ b/net/mac80211/airtime.c
>> > @@ -452,6 +452,9 @@ static u32 ieee80211_get_rate_duration(struct ieee80211_hw *hw,
>> >  			 (status->encoding == RX_ENC_HE && streams > 8)))
>> >  		return 0;
>> >  
>> > +	if (WARN_ON_ONCE(idx >= MCS_GROUP_RATES))
>> > +		return 0;
>> > +
>> 
>> So presumably this is something that can actually happen in real usage,
>> so should we really warn? Or was the driver also fixed to not trigger
>> this?
>
> looking at the mt76x02 support, MT_RATE_INDEX_VHT_IDX is GENMASK(3, 0) so the
> hw can report rate_idx up to 15. Do you prefer to drop WARN_ON_ONCE()? I would
> prefer to keep it since it informs us something nasty occurred (and at the end
> it just runs ones), but I can live even w/o it :)

Well, what I mean is that the purpose of WARN_ON is, as you say, to
catch if "something nasty occurred", so we can fix it. But if we already
know that something nasty does, indeed, occur, shouldn't we just fix the
cause instead of putting in a warn so that we'll get a spat the next
time it happens? :)

-Toke

  reply	other threads:[~2022-11-06 13:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-06 10:30 [PATCH wireless] wifi: mac8021: fix possible oob access in ieee80211_get_rate_duration Lorenzo Bianconi
2022-11-06 12:38 ` Toke Høiland-Jørgensen
2022-11-06 13:32   ` Lorenzo Bianconi
2022-11-06 13:43     ` Toke Høiland-Jørgensen [this message]
2022-11-06 14:11       ` Lorenzo Bianconi
2022-11-06 22:56         ` Toke Høiland-Jørgensen

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=8735aww654.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=bjlockie@lockie.ca \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=nbd@nbd.name \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).