Also, the boundaries between firmware, hardware and (driver) software are pretty murky as far as Wi-Fi drivers are concerned: I remember reading that many FullMAC devices contain their own firmware in a ROM and have some room in on-chip RAM for patches (but not an entirely new firmware image!). These patches can be uploaded at device initialisation time and are contained in the device driver.
This is similar conceptually to microcode, both in that such updates are not persistent (i.e. have to be applied again after every boot) and optional (compared to a mandatory firmware blob upload, you won't notice if your driver is outdated or simply not installing updates for a known vulnerability).
> Also, the boundaries between firmware, hardware and (driver) software are pretty murky as far as Wi-Fi drivers are concerned
Yeah, this is why I ask if it can be fixed via software. I've been utterly surprised at the amount of bugs that exist in firmware but can be mitigated on the seemingly software-side of things.
I have a device that used the brcmfmac driver on Linux until today, and am hoping I won't have to shelve it forever.
No need to shelve the device, just don't treat WiFi as a "trusted zone" and use better encryption on top of WPA2. You should anyway, and this vulnerability is just another small reason why. What this vulnerability does -- as I understand it -- is, when a device dissociates with the network, send the rest of the tx buffer with a zero'd out encryption key. And thus leaks a small amount of data. Not good, however if you apply common best practices to your network I wouldn't lose any sleep over it.
edit: I can't reply to the comment below about iOS updates because the comment is dead, but I just would like to interject that iOS and macOS updates can, and sometimes do, contain firmware updates for hardware. The release notes for the macOS update that contains the fix doesn't specify if the fix is in firmware or software, but I suspect it is in the former.