On Tue, 2024-06-18 at 13:56 +0000, Sperling, Tobias wrote:
> > > >
> Looking to the supplicant the problematic code is in the following function.
> When WPA_DRIVER_FLAGS_CONTROL_PORT is set, during rekeying at the time
> of frame 4/4 the (new) PTK is not yet installed and therefore, leading to the
> frame being unencrypted. The additional check for PTK being installed is probably
> to prevent some race conditions. At least that's what I think after reading the
> commit messages of when control port was introduced.
>
> int wpa_ether_send(struct wpa_supplicant *wpa_s, const u8 *dest,
> u16 proto, const u8 *buf, size_t len)
> {
> [...]
> if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_CONTROL_PORT) {
> int encrypt = wpa_s->wpa &&
> wpa_sm_has_ptk_installed(wpa_s->wpa);
Yeah I think the issue here might have been that this frame is queued up
for transmission, then the key is installed, and then it really is
transmitted - so then it might be encrypted when it shouldn't be.
But tracking whether the *current* PTK is installed is wrong in the
rekey case since the packets should be encrypted with the *old* PTK,
which ... will have the same race?
johannes
