From: Johannes Berg <johannes@sipsolutions.net>
To: Alexander Wetzel <alexander@wetzel-home.de>,
linux-wireless@vger.kernel.org
Subject: Re: BUG: KASAN: use-after-free in ieee80211_mgd_auth
Date: Mon, 16 Jan 2023 15:42:06 +0100 [thread overview]
Message-ID: <1d2ac266daf0e68d60d5a7074f96b2962c733a41.camel@sipsolutions.net> (raw)
In-Reply-To: <20230112173808.6205-1-alexander@wetzel-home.de>
Hi Alexander,
> if (req->key && req->key_len) {
You get into this with this code, I believe?
> // OK, no pointers. Can write into that
> auth_data->key_len = req->key_len;
> auth_data->key_idx = req->key_idx;
> memcpy(auth_data->key, req->key, req->key_len);
> }
>
> // The following line is the one KASAN complains about.
> // But we line itself looks ok for me...
> // We are using "fresh" allocated mem nobody but us knows (yet) about.
> auth_data->algorithm = auth_alg;
>
> ///////////////////////////////////////////////////////////////////////////////
>
>
> Here the KASAN report:
> (gdb) list *ieee80211_mgd_auth+0x59f
> 0x19fbcf is in ieee80211_mgd_auth (net/mac80211/mlme.c:6741).
> 6736 auth_data->key_len = req->key_len;
> 6737 auth_data->key_idx = req->key_idx;
> 6738 memcpy(auth_data->key, req->key, req->key_len);
> 6739 }
> 6740
> 6741 auth_data->algorithm = auth_alg;
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?
And I think the answer is some issue in cfg80211:
> Jan 11 12:37:35 debian kernel: CPU: 6 PID: 624 Comm: wpa_supplicant Not tainted 6.2.0-rc2-wt+ #10
> Jan 11 12:37:35 debian kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
> Jan 11 12:37:35 debian kernel: Call Trace:
> Jan 11 12:37:35 debian kernel: kasan_check_range+0x35/0x1b0
> Jan 11 12:37:35 debian kernel: memcpy+0x20/0x60
> Jan 11 12:37:35 debian kernel: ieee80211_mgd_auth+0x59f/0xc50 [mac80211]
> Jan 11 12:37:35 debian kernel: cfg80211_mlme_auth+0x298/0x570 [cfg80211]
> Jan 11 12:37:35 debian kernel: cfg80211_conn_do_work+0xbd1/0x1020 [cfg80211]
> Jan 11 12:37:35 debian kernel: cfg80211_sme_connect+0x51f/0xa90 [cfg80211]
> Jan 11 12:37:35 debian kernel: cfg80211_connect+0x986/0xda0 [cfg80211]
We came from cfg80211_mlme_auth() from cfg80211_connect(), so cfg80211's
SME.
> Jan 11 12:37:35 debian kernel: Allocated by task 624:
> Jan 11 12:37:35 debian kernel: kasan_save_stack+0x1e/0x40
> Jan 11 12:37:35 debian kernel: kasan_set_track+0x21/0x30
> Jan 11 12:37:35 debian kernel: __kasan_kmalloc+0x7a/0x90
> Jan 11 12:37:35 debian kernel: __kmalloc_node_track_caller+0x60/0x140
> Jan 11 12:37:35 debian kernel: kmemdup+0x1f/0x40
> Jan 11 12:37:35 debian kernel: cfg80211_mgd_wext_connect+0x2bb/0x560 [cfg80211]
> Jan 11 12:37:35 debian kernel: cfg80211_mgd_wext_siwessid+0x4b4/0x660 [cfg80211]
Here it was allocated.
> Jan 11 12:37:35 debian kernel: Freed by task 40321:
>
> Jan 11 12:37:35 debian kernel: cfg80211_upload_connect_keys+0x1e4/0x700 [cfg80211]
> Jan 11 12:37:35 debian kernel: __cfg80211_connect_result+0xfd2/0x18d0 [cfg80211]
> Jan 11 12:37:35 debian kernel: cfg80211_rx_assoc_resp+0x606/0x1160 [cfg80211]
> Jan 11 12:37:35 debian kernel: ieee80211_rx_mgmt_assoc_resp.cold+0x784/0xea6 [mac80211]
> Jan 11 12:37:35 debian kernel: ieee80211_sta_rx_queued_mgmt+0x358/0xed0 [mac80211]
> Jan 11 12:37:35 debian kernel: ieee80211_iface_work+0x19b/0x410 [mac80211]
> Jan 11 12:37:35 debian kernel: process_one_work+0x684/0x1040
but this gives us a hint where it was freed
I think you might just be hitting some strange sequence of things? Or
it's just some really ancient bug?
I started looking at this but I guess the sequence shouldn't really
happen? Perhaps the fix is to either clear wdev->conn.params[*].cipher,
.key and .keylen when connect_keys go away, but that seems odd - maybe
we just need to copy the key into wdev->conn.key and not have that as a
pointer?
johannes
next prev parent reply other threads:[~2023-01-16 14:54 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 [this message]
2023-01-23 21:50 ` Alexander Wetzel
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=1d2ac266daf0e68d60d5a7074f96b2962c733a41.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=alexander@wetzel-home.de \
--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.