WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/net80211?h=jd%2Fsimplify-queueing 2020-06-08T09:09:58Z 2020-06-08T09:09:58Z stsp stsp@openbsd.org 2020-06-08T09:09:58Z urn:sha1:637152b3d67345e3d112b7ce6cc53f0f09b4372c use-after-free when a wireless device is detached. Pseudo-driver detach hooks may end up calling back into the driver, e.g. via an ioctl. So these hooks must run before net80211 data structures are freed. Reported by ratchov@ who saw the following trace when athn(4) detached while it was part of a trunk(4) interface. The trunk(4) detach hooks were run after ieee80211_ifdetach() had been run by athn_detach(). These hooks called back into the driver via athn_ioctl() which now operated on freed memory. uvm_fault(0xffffffff81facdd0, 0xb14, 0, 1) -> e kernel: page fault trap, code=0 Stopped at ieee80211_ba_del+0x20: cmpl $0,0x2c(%r15) ddb{0}> ieee80211_ba_del(0) at ieee80211_ba_del+0x20 ieee80211_newstate(ffff8000000c1048,0,ffffffff) at ieee80211_newstate+0xb51 athn_stop(ffff8000000c1048,1) at athn_stop+0x70 athn_ioctl(ffff8000000c1048,80206910,ffff800014d63800) at athn_ioctl+0x15b ifnewlladdr(ffff8000000c1048) at ifnewlladdr+0x100 trunk_port_destroy(ffff800000589800) at trunk_port_destroy+0x320 if_hooks_run(ffff8000000c10b8) at if_hooks_run+0xb0 if_deactivate(ffff8000000c1048) at if_deactivate+0x24 ether_ifdetach(ffff8000000c1048) at ether_ifdetach+0x1d athn_detach(ffff8000000c1000) at athn_detach+0x17b athn_pci_detach(ffff8000000c1000,1) at athn_pci_detach+0x2a config_detach(ffff8000000c1000,1) at config_detach+0x156 config_detach_children(ffff8000000b7500,1) at config_detach_children+0x58 pci_detach_devices(ffff8000000b7500,1) at pci_detach_devices+0x24 ppb_hotplug_remove(ffff800000033e00) at ppb_hotplug_remove+0x35 taskq_thread(ffffffff81f4bd48) at ok mpi@ ratchov@ 2020-06-01T08:51:13Z stsp stsp@openbsd.org 2020-06-01T08:51:13Z urn:sha1:235b1081ef99fbfa585a9ae33b98a8ec3a6ad78f There are access points out there which insist on establishing a block ack agreement with the client before the WPA handshake can complete. This is sad, but we cannot operate against such APs if we require the handshake to complete first. This reverts CVS commit 4wXCjWU3qNtIX7gW. Problem reported and fix tested by Brandon Sahlin on bugs@ 2020-05-31T09:11:12Z stsp stsp@openbsd.org 2020-05-31T09:11:12Z urn:sha1:fbf3f982a542f8250e3dc06ba428c97b9d46bbe2 2020-05-31T09:08:33Z stsp stsp@openbsd.org 2020-05-31T09:08:33Z urn:sha1:657bc46d951277cea3a1b922a2a7a9547526bbfd Patch by Mikolaj Kucharski 2020-05-29T07:37:51Z stsp stsp@openbsd.org 2020-05-29T07:37:51Z urn:sha1:d64dd7a521be1afbc52ea2a3f7ad09ac19babbe7 complete group key renewal immediately. The old code would not install the new group key unless a station in need of re-keying was present. Tested by Mikolaj Kucharski on bugs@ 2020-05-29T07:34:19Z stsp stsp@openbsd.org 2020-05-29T07:34:19Z urn:sha1:21da8b5c4ff376fa03b185235c96ba3e9069b96b associated clients and before switching over to the new group key, purge the AP's global power-save frame queue. This queue may contain group-addressed frames which were encrypted with the old group key. Clients will not be able to decrypt such frames, and purging the queue prevents a panic ("key unset for sw crypto") where athn(4) attempts to transmit such frames from its software beacon alert interrupt handler. This is another variant of the problem fixed in CVS commit ufdFLtcLfPRrbshM. Panic reported and fix tested by Mikolaj Kucharski on bugs@ 2020-05-26T11:45:32Z stsp stsp@openbsd.org 2020-05-26T11:45:32Z urn:sha1:6b204e2a39b4657667618235b79513ae677598b9 Some drivers, such as ral(4), cannot provide the IV required for a replay check because hardware strips the IV before passing the frame to the driver. Which means frames with the RXI_HWDEC flag but without the 'protected' bit set in the frame header must be passed without any further verification and without updating the last-seen packet number. All we can do is hope that these devices perform replay checking correctly. Fixes a regression where some ral(4) devices would fail to receive packets on encrypted networks. Reported and fix confirmed by Hendrik Meyburgh. ok mpi@ 2020-05-19T18:57:57Z stsp stsp@openbsd.org 2020-05-19T18:57:57Z urn:sha1:1934f67d20a306af52546ffd57dda869223f938a Association to some access points breaks without the ESS capability bit. Apparently I misunderstood something. Reported by krw@ and tb@ 2020-05-19T08:34:19Z stsp stsp@openbsd.org 2020-05-19T08:34:19Z urn:sha1:9289be61e36b9c317b07e691123470ea405687f7 The ESS capability bit should be set if the transmitter is an AP. Association requests are sent by clients. ok jca@ 2020-05-15T14:21:08Z stsp stsp@openbsd.org 2020-05-15T14:21:08Z urn:sha1:e995d5233c2b070c8991cbdcf9e2fdcd7d598966 So far, drivers using hardware CCMP decryption were expected to keep the most recently seen CCMP packet number (PN) up-to-date, and to discard frames with lower PNs as replays. A-MPDU subframes may legitimately arrive out of order, and the drivers skipped CCMP replay checking for such frames. Re-ordering happens in ieee80211_inputm(), after the driver is done with a frame. Drivers cannot tell replayed frames apart from legitimate out-of-order retransmissions. To fix this, update the PN value in ieee80211_inputm() after subframes have been reordered into their proper sequence. Drivers still perform replay checks but they no longer have to worry about updating the last seen PN value. The 802.11 spec confirms that replay checking is supposed to happen after A-MPDU re-ordering. Tested by jmc@, benno@, solene@, and myself with the following drivers: athn(4), iwn(4), iwm(4), wpi(4), urtwn(4) ok solene@