lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5a1d1244c8d3e20408732858442f264d26cc2768.camel@sipsolutions.net>
Date:   Mon, 13 Feb 2023 12:01:43 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Marc Bornand <dev.mbornand@...temb.ch>,
        linux-wireless@...r.kernel.org
Cc:     "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Kalle Valo <kvalo@...nel.org>,
        Yohan Prod'homme <kernel@...do.fr>, stable@...r.kernel.org
Subject: Re: [PATCH v2] Set ssid when authenticating

On Mon, 2023-02-13 at 10:55 +0000, Marc Bornand wrote:
> changes since v1:
> - add some informations
> - test it on wireless-2023-01-18 tag
> - no real code change
> 
> When a connexion was established without going through
> NL80211_CMD_CONNECT, the ssid was never set in the wireless_dev struct.
> Now we set it during when an NL80211_CMD_AUTHENTICATE is issued.

This is incorrect, doing an authentication doesn't require doing an
association afterwards, and doesn't necessarily imply any state change
in the kernel.

> alternatives:
> 1. Do the same but during association and not authentication.

Which should probably be done _after_ successful authentication, even in
the CONNECT command case, which currently does it in cfg80211_connect()
but I guess that should move to __cfg80211_connect_result().

> 2. use ieee80211_bss_get_elem in nl80211_send_iface, this would report
>    the right ssid to userspace, but this would not fix the root cause,
>    this alos wa the behavior prior to 7b0a0e3c3a882 when the bug was
>    introduced.

That would be OK too but the reason I changed it there (missing the fact
that it wasn't set) is that we have multiple BSSes with MLO. So it's
hard to get one to do this with.

johannes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ