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
