Probably not all BCM43xx devices are affected, though. This product line spans over 10 years and all 802.11 revisions since a/b with various firmwares and internal CPUs, from custom cores to ARM.

The issue likely exists in a limited number of chips, possibly only FullMAC ones, like similar bug found earlier by Google:

https://googleprojectzero.blogspot.com/2017/04/over-air-expl...

edit:

Actually NIST lists the vulnerable NICs: BCM4354, BCM4358, BCM4359.

NIST's list is incomplete, at least BCM43570 is vulnerable as well [1]. I would expect many more Broadcom chips to be vulnerable even if exploits may need to be tweaked.

[1] I'm part of a team that develops a product with this chip, and I've used the hostapd configuration I linked elsewhere in this topic to show it is vulnerable.

Mostly. If this is the same thing that was posted in the last month or so, then it's possible for it be patched. Whether it's the firmware itself or through a mitigation technique in the OS, I can't remember. The last time it was posted, it was mostly about phones, and there was an update for Android phones that "fixed" the bug. The status of the bug on iOS was unknown.

It may be that the bug is easily defendable against at the OS level if one knows that it could be present.

Edit: Somebody else posted the previous discussion, so I think it's the bug I'm thinking of.

In general the firmware for these devices is loaded by the OS at startup, so the OS simply patches the firmware file. Checking the linux-firmware tree for what I presume to be the same devices, though, I see a few recent commits to a handful of files, but nothing that looks like it might be a fix to this issue:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...