Marking this as security bug since the log message suggests this is a firmware crash that may be exploitable. Further investigation necessary, might have to consult with Broadcom.

mnissler -- Does this imply to you a bug in the firmware, or in the driver?  And does the OS have the capability to upgrade the firmware?

The Chrome & OS versions are fairly old.  Can you repro with a recent version?

nparker: is there a particular customer that has the devices pinned to M55 until summer break (or something like that)? Does this customer require support on M55?

Even if "Yes", it would be help to describe the test with M58 or M59 in better detail (e.g. describe hotspot config in detail: which band and which type of security was used)

I agree it sounds like a bug with BCM FW. But I'll point out Chrome OS user space also behaves differently in newer releases:  M55 shipped with wpa_supplicant-2.3 and IIRC M57 was the first release to use wpa_supplicant-2.5 - something like 6000 changes between the two in the upstream git repo.

Re comments #2 and #3: The version I ran just happens to be the last build I installed before going on a 3-month leave from which I now returned :) I'm happy to try and repro with a more recent build next week.

I was hoping the WiFi connection parameters would be evident from the debug log tarball, but I can certainly get that info for you.

Regarding my take on what happens: I found this while attempting to repro the attack described here https://googleprojectzero.blogspot.de/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html

My marginal understanding of the kernel driver suggests that the log message indeed indicates a firmware crash in the WiFi SoC. Since it's unclear at this point whether the bug gets triggered due to a buggy kernel driver or a remote event, I've opted to mark this as a security bug just in case. However, no urgency for now - I'll see what happens with newer versions and then we can take it from there. Since the bug is pretty annoying, I just wanted to make sure I file it before I forget.

I don't recall any recent churn in this area.  The most recent commit in drivers/net/wireless-3.8/brcm80211/ in the 3.14 tree is from 2016-06-24.  third_party/linux-firmware/brcm has not changed since 2016-01-28.

Intel sends us new drops on a pretty regular basis.  Broadcom, maybe not so much.  I don't think I've heard from them since the Ryu days.

> brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

The driver doesn't seem to treat this as a fatal condition, but I wonder if there is something missing from our version of the brcmfmac driver and that is causing mismatched expectations between the FW and the driver.

I checked brcmfmac in Linux ToT and bcmdhd in the android-tegra-flounder-3.10 branch, but none of them define bit 4 (which is triggering the error):

/* tohostmailboxdata */
#define HMB_DATA_NAKHANDLED	1	/* retransmit NAK'd frame */
#define HMB_DATA_DEVREADY	2	/* talk to host after enable */
#define HMB_DATA_FC		4	/* per prio flowcontrol update flag */
#define HMB_DATA_FWREADY	8	/* fw ready for protocol activity */

I'm going to close this WontFix as I'm no longer able to reproduce on a current dev build. I'm not sure it is the more recent OS build that fixes things. Maybe it is, in which case we should be good. But it might also be that the AP disappearing triggered a crash that was root-caused by other testing I did. Anyhow, it doesn't matter what it is, we can't do much anyways if we can no longer reproduce.