Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1d2ac266daf0e68d60d5a7074f96b2962c733a41.camel@sipsolutions.net>
Subject: Re: BUG: KASAN: use-after-free in ieee80211_mgd_auth
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Alexander Wetzel <alexander@wetzel-home.de>,
        linux-wireless@vger.kernel.org
Date:   Mon, 16 Jan 2023 15:42:06 +0100
In-Reply-To: <20230112173808.6205-1-alexander@wetzel-home.de>
References: <20230112173808.6205-1-alexander@wetzel-home.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) 
MIME-Version: 1.0
Precedence: bulk

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 =3D req->key_len;
> 		auth_data->key_idx =3D req->key_idx;
> 		memcpy(auth_data->key, req->key, req->key_len);
> 	}
>=20
> // 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 =3D auth_alg;
>=20
> /////////////////////////////////////////////////////////////////////////=
//////
>=20
>=20
> 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 =3D req->key_len;
> 6737                    auth_data->key_idx =3D req->key_idx;
> 6738                    memcpy(auth_data->key, req->key, req->key_len);
> 6739            }
> 6740
> 6741            auth_data->algorithm =3D auth_alg;

I think this is misleading you.

> Jan 11 12:37:35 debian kernel: BUG: KASAN: use-after-free in ieee80211_mg=
d_auth+0x59f/0xc50 [mac80211]
> Jan 11 12:37:35 debian kernel: Read of size 13 at addr ffff8881608bd4a0 b=
y 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 t=
ainted 6.2.0-rc2-wt+ #10
> Jan 11 12:37:35 debian kernel: Hardware name: QEMU Standard PC (Q35 + ICH=
9, 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 [cfg80=
211]
> Jan 11 12:37:35 debian kernel:  cfg80211_sme_connect+0x51f/0xa90 [cfg8021=
1]
> 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 [cf=
g80211]
> Jan 11 12:37:35 debian kernel:  cfg80211_mgd_wext_siwessid+0x4b4/0x660 [c=
fg80211]

Here it was allocated.

> Jan 11 12:37:35 debian kernel: Freed by task 40321:
>=20
> 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 [c=
fg80211]
> Jan 11 12:37:35 debian kernel:  cfg80211_rx_assoc_resp+0x606/0x1160 [cfg8=
0211]
> Jan 11 12:37:35 debian kernel:  ieee80211_rx_mgmt_assoc_resp.cold+0x784/0=
xea6 [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 [mac8021=
1]
> 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