From: Alexander Wetzel <alexander@wetzel-home.de>
To: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org
Subject: Re: BUG: KASAN: use-after-free in ieee80211_mgd_auth
Date: Mon, 23 Jan 2023 22:50:30 +0100 [thread overview]
Message-ID: <c80f04d2-8159-a02a-9287-26e5ec838826@wetzel-home.de> (raw)
In-Reply-To: <1d2ac266daf0e68d60d5a7074f96b2962c733a41.camel@sipsolutions.net>
On 16.01.23 15:42, Johannes Berg wrote:
> Hi Alexander,
>
>> if (req->key && req->key_len) {
>
> You get into this with this code, I believe?
>
That we get into that code turns out to be a red flag already:
The hostapd test wext_pmf is using WPA2.
While req->key is only for WEP!!
> I think this is misleading you.
>
>> Jan 11 12:37:35 debian kernel: BUG: KASAN: use-after-free in ieee80211_mgd_auth+0x59f/0xc50 [mac80211]
>> Jan 11 12:37:35 debian kernel: Read of size 13 at addr ffff8881608bd4a0 by task wpa_supplicant/624
>
> Clearly, that is reporting a 13-byte memcpy(), and a *read* at that too,
> so it must be req->key that's being used after free?
>
That was the tip I needed to unravel that mystery. Thanks.
I documented my findings in this mail, mostly for myself.
> And I think the answer is some issue in cfg80211:
Looks like this is happening:
wireless_dev has a wext compat structure:
@wext: (private) Used by the internal wireless extensions compat code
which has a field control:
@wext.connect: (private) connection handling data
When using WEP cfg80211_connect() is setting a pointer to the WEP key:
if (cipher == WLAN_CIPHER_SUITE_WEP40 ||
cipher == WLAN_CIPHER_SUITE_WEP104) {
connect->key_idx = idx;
connect->key = connkeys->params[idx].key;
connect->key_len = connkeys->params[idx].key_len;
But nobody zeros connect->key and connect->key_len.
Which is really wext.connect->key (and so on) on the interface level
when using wext.
cfg80211_sme_connect() is then copying the wext.connect structure into
&wdev->conn->params with our then invalid pointer.
cfg80211_conn_do_work() is then finally copying the invalid key pointer
and len data into a private struct cfg80211_auth_request auth_req which
is handed over to eee80211_mgd_auth().
Which then tries to access memory freed when the last WEP handshake on
the interface completed.
KASAN happily points out the worker freeing the memory. Which was a task
completely unrelated to the current assoc.
In other words: When we first connect with WEP and later (on the same
interface) with WPA we have a key_len and pointer left from the last WEP
connect. And ieee80211_mgd_auth() then tries to access the deleted key
via the remaining pointer.
Which now makes it strange that the hostapd test runs were often working...
Someone else must have reused the memory with at least one of the two
checked values being zero.
> I think you might just be hitting some strange sequence of things? Or
> it's just some really ancient bug?
>
Ancient bug. The problematic code was added with
'commit fffd0934b939 ("cfg80211: rework key operation")'
in 2009, kernel 2.6.32.
The fix is trivial, I'll probably just zero key and key-len when not
using wext. But maybe I find a more wext-only solution.
I'll submit a patch tomorrow.
Alexander
next prev parent reply other threads:[~2023-01-23 21:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 17:38 BUG: KASAN: use-after-free in ieee80211_mgd_auth Alexander Wetzel
2023-01-16 14:42 ` Johannes Berg
2023-01-23 21:50 ` Alexander Wetzel [this message]
2023-01-24 8:15 ` Johannes Berg
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=c80f04d2-8159-a02a-9287-26e5ec838826@wetzel-home.de \
--to=alexander@wetzel-home.de \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.