/lib/firmware/brcm/brcmfmac4358-pcie.bin appears to be the relevant firmware, and is currently dated 2016-09-13 prior to the vulnerability fix.
Thank you, security-kernel project handles kernel related vulnerabilities. Gentoo Security Padawan ChrisADR
What needs to be done here? All vulnerable versions are gone long ago from the tree. Should users be informed?
Are you sure it's fixed? https://leeneubecker.com/raspberry-pi-patch-to-protect-against-broadpwn-pre-released/ indicates the fix was part of a 2017-08-08 firmware, yet sys-kernel/linux-firmware-20190815 still has a Broadcom firmware dated 2017-06-02...
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=17e6288135d4500f9fe60224dce2b46d850c346b says that CVE-2017-9417 is fixed for brcmfmac4358-pcie.bin since 2017-11-25 (also this was fixed for bcm4354 and bcm4356 on the same day) Maybe I'm missing something. Which chipset/firmware file is still vulnerable to broadpwn?
# strings /lib/firmware/brcm/brcmfmac4358-pcie.bin | grep Date: 4358a3-roml/pcie-ag-p2p-pno-aoe-pktfilter-keepalive-sr-mchan-pktctx-hostpp-lpc-pwropt-txbf-wl11u-mfp-betdls-amsdutx5g-txpwr-rcc-wepso-sarctrl-btcdyn-xorcsum-proxd-gscan-linkstat-ndoe-hs20sta-oobrev-hchk-logtrace-rmon-apf-d11status-fie Version: 7.112.300.12 (r702724) CRC: 8fadde44 Date: Fri 2017-06-02 17:28:25 PDT Ucode Ver: 963.317 FWID: 01-f92b9ce0
Someone did an analysis on the bcm4358 and found the firmware dated 2017-06-02 not vulnerable to broadpwn: http://boosterok.com/blog/broadpwn/ using a slightly different version though
Anyway, nothing for kernel team to do here, the exploit is for the firmware which runs inside the Broadcom wifi chip.
(In reply to Chí-Thanh Christopher Nguyễn from comment #7) > Anyway, nothing for kernel team to do here, the exploit is for the firmware > which runs inside the Broadcom wifi chip. But the firmware is part of sys-kernel/linux-firmware, which has metadata.xml making it part of the kernel project?
Thinko, I meant kernel security team. But following bump and cleanup, the security team and not the maintainers take it from there.
[22:25:34] <ajak> 20171009 and 20171123 removed jan 2018 This should've had a GLSA, but bit late now. Closing, thanks ajak.