On 13/08/19(Tue) 14:58, Stefan Sperling wrote: > On Tue, Aug 13, 2019 at 09:40:22AM -0300, Martin Pieuchot wrote: > > On 13/08/19(Tue) 13:52, Stefan Sperling wrote: > > > This should hopefully prevent a crash reported to me by Jesper Wallin, > > > where net80211 crashes when it attempts to decrypt a CCMP-encrypted > > > frame which iwm passed up without decrypting it first. > > > > How does the stack crashes? > > Jesper only sent me a screen shot and no public bug report :( > > The trace looks roughly like this, where AES_Encrypt_ECB crashes because > ieee80211_ccmp_set_key() is never called since iwm_set_key overrides it.
Could we call ieee80211_ccmp_set_key() with a default value when initializing the stack then? Would that prevent all the possible family of bugs? What problems can occur when passing encrypted frames to the stack without having configure a CCMP key? Are they packets going to be dropped at some point? > AES_Encrypt_ECB() > ieee80211_ccmp_phase1() > ieee80211_ccmp_decrypt() > ieee80211_input() > ieee80211_ba_move_window() > ieee80211_input() > iwm_rx_rx_mpdu() > iwm_notif_intr() > iwm_intr() > > What's a bit confusing here is that the interrupt was for an uencrypted > frame (a Block Ack Request) which moved the BA window forward. When > this happens we flush frames currently waiting in the Rx BA reordering > buffer. The encrypted frame which caused the crash was on that queue; > It must have passed through iwm_rx_rx_mpdu() earlier before the WPA > handshake was complete, and ended up waiting in the Rx BA queue because > its sequence number was off. > > Shouldn't we drop this packet in the stack as well? > > net80211 will always see a 'protected' bit in the frame header > In ieee80211_input, if rxi has an HW_DEC flag set, the code assumes > this frame needs no further processing for crypto. > Otherwise it tries to decrypt. > > So if the driver passes up a frame without decrypting it and without > setting HW_DEC, we crash. There's nothing that would allow net80211 > to detect an incorrect absence of HW_DEC. The driver overrides the > set_key function and corresponding frames are expected to arrive with > the HW_DEC flag set in net80211. (Please don't ask me to change this > design right now for a better fix, it wasn't my idea...) See above, if the crash is because of a missing key, put one :)
