<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/wireless/broadcom, branch v5.4.50</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.50</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.50'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-06-22T07:31:19+00:00</updated>
<entry>
<title>b43_legacy: Fix connection problem with WPA3</title>
<updated>2020-06-22T07:31:19+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2020-05-26T15:59:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3ef00d99199d5a18648bbb7740b455c299d68b74'/>
<id>urn:sha1:3ef00d99199d5a18648bbb7740b455c299d68b74</id>
<content type='text'>
commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream.

Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43legacy did not report that it could handle them. By setting MFP_CAPABLE using
ieee80211_set_hw(), the problem is fixed.

With this change, b43legacy will handle the ciphers it knows in hardware,
and let mac80211 handle the others in software. It is not necessary to
use the module parameter NOHWCRYPT to turn hardware encryption off.
Although this change essentially eliminates that module parameter,
I am choosing to keep it for cases where the hardware is broken,
and software encryption is required for all ciphers.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: Stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200526155909.5807-3-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>b43: Fix connection problem with WPA3</title>
<updated>2020-06-22T07:31:19+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2020-05-26T15:59:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b74d369d2962251276925c91058f6046aec6baf5'/>
<id>urn:sha1:b74d369d2962251276925c91058f6046aec6baf5</id>
<content type='text'>
commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream.

Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43 did not report that it could handle them. By setting MFP_CAPABLE using
ieee80211_set_hw(), the problem is fixed.

With this change, b43 will handle the ciphers it knows in hardware,
and let mac80211 handle the others in software. It is not necessary to
use the module parameter NOHWCRYPT to turn hardware encryption off.
Although this change essentially eliminates that module parameter,
I am choosing to keep it for cases where the hardware is broken,
and software encryption is required for all ciphers.

Reported-and-tested-by: Rui Salvaterra &lt;rsalvaterra@gmail.com&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: Stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200526155909.5807-2-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>b43legacy: Fix case where channel status is corrupted</title>
<updated>2020-06-22T07:31:19+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2020-04-07T19:00:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c039a9921b3287376700808cbdac591c9fd125e'/>
<id>urn:sha1:5c039a9921b3287376700808cbdac591c9fd125e</id>
<content type='text'>
commit ec4d3e3a054578de34cd0b587ab8a1ac36f629d9 upstream.

This patch fixes commit 75388acd0cd8 ("add mac80211-based driver for
legacy BCM43xx devices")

In https://bugzilla.kernel.org/show_bug.cgi?id=207093, a defect in
b43legacy is reported. Upon testing, thus problem exists on PPC and
X86 platforms, is present in the oldest kernel tested (3.2), and
has been present in the driver since it was first added to the kernel.

The problem is a corrupted channel status received from the device.
Both the internal card in a PowerBook G4 and the PCMCIA version
(Broadcom BCM4306 with PCI ID 14e4:4320) have the problem. Only Rev, 2
(revision 4 of the 802.11 core) of the chip has been tested. No other
devices using b43legacy are available for testing.

Various sources of the problem were considered. Buffer overrun and
other sources of corruption within the driver were rejected because
the faulty channel status is always the same, not a random value.
It was concluded that the faulty data is coming from the device, probably
due to a firmware bug. As that source is not available, the driver
must take appropriate action to recover.

At present, the driver reports the error, and them continues to process
the bad packet. This is believed that to be a mistake, and the correct
action is to drop the correpted packet.

Fixes: 75388acd0cd8 ("add mac80211-based driver for legacy BCM43xx devices")
Cc: Stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Reported-and-tested by: F. Erhard &lt;erhard_f@mailbox.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200407190043.1686-1-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>brcmfmac: fix wrong location to get firmware feature</title>
<updated>2020-06-22T07:30:58+00:00</updated>
<author>
<name>Jaehoon Chung</name>
<email>jh80.chung@samsung.com</email>
</author>
<published>2020-03-30T05:25:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=22a7346168245d846a538241eed0c66a7ebaf751'/>
<id>urn:sha1:22a7346168245d846a538241eed0c66a7ebaf751</id>
<content type='text'>
[ Upstream commit c57673852062428cdeabdd6501ac8b8e4c302067 ]

sup_wpa feature is getting after setting feature_disable flag.
If firmware is supported sup_wpa feature,  it's always enabled
regardless of feature_disable flag.

Fixes: b8a64f0e96c2 ("brcmfmac: support 4-way handshake offloading for WPA/WPA2-PSK")
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200330052528.10503-1-jh80.chung@samsung.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: abort and release host after error</title>
<updated>2020-04-08T07:08:41+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2020-01-28T22:14:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cec4be18d1367ec9c57222e4b3ab96d22a60b029'/>
<id>urn:sha1:cec4be18d1367ec9c57222e4b3ab96d22a60b029</id>
<content type='text'>
[ Upstream commit 863844ee3bd38219c88e82966d1df36a77716f3e ]

With commit 216b44000ada ("brcmfmac: Fix use after free in
brcmf_sdio_readframes()") applied, we see locking timeouts in
brcmf_sdio_watchdog_thread().

brcmfmac: brcmf_escan_timeout: timer expired
INFO: task brcmf_wdog/mmc1:621 blocked for more than 120 seconds.
Not tainted 4.19.94-07984-g24ff99a0f713 #1
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
brcmf_wdog/mmc1 D    0   621      2 0x00000000 last_sleep: 2440793077.  last_runnable: 2440766827
[&lt;c0aa1e60&gt;] (__schedule) from [&lt;c0aa2100&gt;] (schedule+0x98/0xc4)
[&lt;c0aa2100&gt;] (schedule) from [&lt;c0853830&gt;] (__mmc_claim_host+0x154/0x274)
[&lt;c0853830&gt;] (__mmc_claim_host) from [&lt;bf10c5b8&gt;] (brcmf_sdio_watchdog_thread+0x1b0/0x1f8 [brcmfmac])
[&lt;bf10c5b8&gt;] (brcmf_sdio_watchdog_thread [brcmfmac]) from [&lt;c02570b8&gt;] (kthread+0x178/0x180)

In addition to restarting or exiting the loop, it is also necessary to
abort the command and to release the host.

Fixes: 216b44000ada ("brcmfmac: Fix use after free in brcmf_sdio_readframes()")
Cc: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Cc: Brian Norris &lt;briannorris@chromium.org&gt;
Cc: Douglas Anderson &lt;dianders@chromium.org&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Acked-by: franky.lin@broadcom.com
Acked-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>b43legacy: Fix -Wcast-function-type</title>
<updated>2020-02-24T07:36:37+00:00</updated>
<author>
<name>Phong Tran</name>
<email>tranmanphong@gmail.com</email>
</author>
<published>2019-11-26T17:55:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc8746721cdf974890655311f56e91a6b4257ea0'/>
<id>urn:sha1:bc8746721cdf974890655311f56e91a6b4257ea0</id>
<content type='text'>
[ Upstream commit 475eec112e4267232d10f4afe2f939a241692b6c ]

correct usage prototype of callback in tasklet_init().
Report by https://github.com/KSPP/linux/issues/20

Tested-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Phong Tran &lt;tranmanphong@gmail.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: sdio: Fix OOB interrupt initialization on brcm43362</title>
<updated>2020-02-24T07:36:30+00:00</updated>
<author>
<name>Jean-Philippe Brucker</name>
<email>jean-philippe@linaro.org</email>
</author>
<published>2019-12-26T09:20:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6f65dd66ea6f71a6dcbc9bba1853327ec4e4c457'/>
<id>urn:sha1:6f65dd66ea6f71a6dcbc9bba1853327ec4e4c457</id>
<content type='text'>
[ Upstream commit 8c8e60fb86a90a30721bbd797f58f96b3980dcc1 ]

Commit 262f2b53f679 ("brcmfmac: call brcmf_attach() just before calling
brcmf_bus_started()") changed the initialization order of the brcmfmac
SDIO driver. Unfortunately since brcmf_sdiod_intr_register() is now
called before the sdiodev-&gt;bus_if initialization, it reads the wrong
chip ID and fails to initialize the GPIO on brcm43362. Thus the chip
cannot send interrupts and fails to probe:

[   12.517023] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   12.531214] ieee80211 phy0: brcmf_bus_started: failed: -110
[   12.536976] ieee80211 phy0: brcmf_attach: dongle is not responding: err=-110
[   12.566467] brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed

Initialize the bus interface earlier to ensure that
brcmf_sdiod_intr_register() properly sets up the OOB interrupt.

BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908438
Fixes: 262f2b53f679 ("brcmfmac: call brcmf_attach() just before calling brcmf_bus_started()")
Signed-off-by: Jean-Philippe Brucker &lt;jean-philippe@linaro.org&gt;
Reviewed-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: Fix use after free in brcmf_sdio_readframes()</title>
<updated>2020-02-24T07:36:24+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2019-12-03T09:58:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=071963d3714301c7b14c8e71200d9bf5c30925ce'/>
<id>urn:sha1:071963d3714301c7b14c8e71200d9bf5c30925ce</id>
<content type='text'>
[ Upstream commit 216b44000ada87a63891a8214c347e05a4aea8fe ]

The brcmu_pkt_buf_free_skb() function frees "pkt" so it leads to a
static checker warning:

    drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:1974 brcmf_sdio_readframes()
    error: dereferencing freed memory 'pkt'

It looks like there was supposed to be a continue after we free "pkt".

Fixes: 4754fceeb9a6 ("brcmfmac: streamline SDIO read frame routine")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Franky Lin &lt;franky.lin@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: Fix memory leak in brcmf_p2p_create_p2pdev()</title>
<updated>2020-02-24T07:36:23+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2019-11-22T19:19:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=55195593a8c6b12450d36670c9b9d0b7bc974e83'/>
<id>urn:sha1:55195593a8c6b12450d36670c9b9d0b7bc974e83</id>
<content type='text'>
[ Upstream commit 5cc509aa83c6acd2c5cd94f99065c39d2bd0a490 ]

In the implementation of brcmf_p2p_create_p2pdev() the allocated memory
for p2p_vif is leaked when the mac address is the same as primary
interface. To fix this, go to error path to release p2p_vif via
brcmf_free_vif().

Fixes: cb746e47837a ("brcmfmac: check p2pdev mac address uniqueness")
Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: Fix memory leak in brcmf_usbdev_qinit</title>
<updated>2020-02-11T12:35:09+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2019-12-15T01:51:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4e5d1bf6e68f376019161afe62cd809215570dc4'/>
<id>urn:sha1:4e5d1bf6e68f376019161afe62cd809215570dc4</id>
<content type='text'>
commit 4282dc057d750c6a7dd92953564b15c26b54c22c upstream.

In the implementation of brcmf_usbdev_qinit() the allocated memory for
reqs is leaking if usb_alloc_urb() fails. Release reqs in the error
handling path.

Fixes: 71bb244ba2fd ("brcm80211: fmac: add USB support for bcm43235/6/8 chipsets")
Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
