From: Lorenzo Bianconi <lorenzo@kernel.org>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
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, 6 Nov 2022 15:11:04 +0100 [thread overview]
Message-ID: <Y2fAeJHViQqgoFXP@lore-desk> (raw)
In-Reply-To: <8735aww654.fsf@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 3229 bytes --]
> 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? :)
I think in this case the hw just reports a wrong value, so we can limit the
value there too, anyway I would not assume each driver limits the rate_idx
value (as we already do for stream :))
Regards,
Lorenzo
>
> -Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-11-06 14:11 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
2022-11-06 14:11 ` Lorenzo Bianconi [this message]
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=Y2fAeJHViQqgoFXP@lore-desk \
--to=lorenzo@kernel.org \
--cc=bjlockie@lockie.ca \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=toke@toke.dk \
/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).