linux-stable.git/drivers/net/wireless/broadcom, branch v4.9.296 Linux kernel stable tree b43: fix a lower bounds test 2021-11-26T10:48:34+00:00 Dan Carpenter dan.carpenter@oracle.com 2021-10-06T07:36:22+00:00 a97b984a6ec6637d707513bc3c31b4f775704f92 [ Upstream commit 9b793db5fca44d01f72d3564a168171acf7c4076 ] The problem is that "channel" is an unsigned int, when it's less 5 the value of "channel - 5" is not a negative number as one would expect but is very high positive value instead. This means that "start" becomes a very high positive value. The result of that is that we never enter the "for (i = start; i <= end; i++) {" loop. Instead of storing the result from b43legacy_radio_aci_detect() it just uses zero. Fixes: ef1a628d83fc ("b43: Implement dynamic PHY API") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Michael Büsch <m@bues.ch> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211006073621.GE8404@kili Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9b793db5fca44d01f72d3564a168171acf7c4076 ]

The problem is that "channel" is an unsigned int, when it's less 5 the
value of "channel - 5" is not a negative number as one would expect but
is very high positive value instead.

This means that "start" becomes a very high positive value.  The result
of that is that we never enter the "for (i = start; i <= end; i++) {"
loop.  Instead of storing the result from b43legacy_radio_aci_detect()
it just uses zero.

Fixes: ef1a628d83fc ("b43: Implement dynamic PHY API")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Michael Büsch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211006073621.GE8404@kili
Signed-off-by: Sasha Levin <sashal@kernel.org>
b43legacy: fix a lower bounds test 2021-11-26T10:48:33+00:00 Dan Carpenter dan.carpenter@oracle.com 2021-10-06T07:35:42+00:00 482899b0af98e7113bdf31d42a708c790aaeb199 [ Upstream commit c1c8380b0320ab757e60ed90efc8b1992a943256 ] The problem is that "channel" is an unsigned int, when it's less 5 the value of "channel - 5" is not a negative number as one would expect but is very high positive value instead. This means that "start" becomes a very high positive value. The result of that is that we never enter the "for (i = start; i <= end; i++) {" loop. Instead of storing the result from b43legacy_radio_aci_detect() it just uses zero. Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Michael Büsch <m@bues.ch> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211006073542.GD8404@kili Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c1c8380b0320ab757e60ed90efc8b1992a943256 ]

The problem is that "channel" is an unsigned int, when it's less 5 the
value of "channel - 5" is not a negative number as one would expect but
is very high positive value instead.

This means that "start" becomes a very high positive value.  The result
of that is that we never enter the "for (i = start; i <= end; i++) {"
loop.  Instead of storing the result from b43legacy_radio_aci_detect()
it just uses zero.

Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Michael Büsch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211006073542.GD8404@kili
Signed-off-by: Sasha Levin <sashal@kernel.org>
brcmsmac: mac80211_if: Fix a resource leak in an error handling path 2021-07-20T14:21:02+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2021-05-12T20:58:30+00:00 bea9ce6e5eeacc88cb43c49e3ce66d66b6c4d10e [ Upstream commit 9a25344d5177c2b9285532236dc3d10a091f39a8 ] If 'brcms_attach()' fails, we must undo the previous 'ieee80211_alloc_hw()' as already done in the remove function. Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/8fbc171a1a493b38db5a6f0873c6021fca026a6c.1620852921.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9a25344d5177c2b9285532236dc3d10a091f39a8 ]

If 'brcms_attach()' fails, we must undo the previous 'ieee80211_alloc_hw()'
as already done in the remove function.

Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/8fbc171a1a493b38db5a6f0873c6021fca026a6c.1620852921.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sasha Levin <sashal@kernel.org>
b43: N-PHY: Fix the update of coef for the PHY revision >= 3case 2021-03-03T16:44:34+00:00 Colin Ian King colin.king@canonical.com 2021-02-15T12:05:32+00:00 1ea5287697272ee7e50e123c54666aa53e6ef8a0 [ Upstream commit 4773acf3d4b50768bf08e9e97a204819e9ea0895 ] The documentation for the PHY update [1] states: Loop 4 times with index i If PHY Revision >= 3 Copy table[i] to coef[i] Otherwise Set coef[i] to 0 the copy of the table to coef is currently implemented the wrong way around, table is being updated from uninitialized values in coeff. Fix this by swapping the assignment around. [1] https://bcm-v4.sipsolutions.net/802.11/PHY/N/RestoreCal/ Fixes: 2f258b74d13c ("b43: N-PHY: implement restoring general configuration") Addresses-Coverity: ("Uninitialized scalar variable") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4773acf3d4b50768bf08e9e97a204819e9ea0895 ]

The documentation for the PHY update [1] states:

Loop 4 times with index i

    If PHY Revision >= 3
        Copy table[i] to coef[i]
    Otherwise
        Set coef[i] to 0

the copy of the table to coef is currently implemented the wrong way
around, table is being updated from uninitialized values in coeff.
Fix this by swapping the assignment around.

[1] https://bcm-v4.sipsolutions.net/802.11/PHY/N/RestoreCal/

Fixes: 2f258b74d13c ("b43: N-PHY: implement restoring general configuration")
Addresses-Coverity: ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
brcm80211: fix possible memleak in brcmf_proto_msgbuf_attach 2020-10-29T08:05:45+00:00 Wang Yufen wangyufen@huawei.com 2020-07-20T09:36:05+00:00 260de148dda99bdc10ed0faaa0e13a93660abb4b [ Upstream commit 6c151410d5b57e6bb0d91a735ac511459539a7bf ] When brcmf_proto_msgbuf_attach fail and msgbuf->txflow_wq != NULL, we should destroy the workqueue. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1595237765-66238-1-git-send-email-wangyufen@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6c151410d5b57e6bb0d91a735ac511459539a7bf ]

When brcmf_proto_msgbuf_attach fail and msgbuf->txflow_wq != NULL,
we should destroy the workqueue.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Yufen <wangyufen@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1595237765-66238-1-git-send-email-wangyufen@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
brcmsmac: fix memory leak in wlc_phy_attach_lcnphy 2020-10-29T08:05:45+00:00 Keita Suzuki keitasuzuki.park@sslab.ics.keio.ac.jp 2020-09-08T12:17:41+00:00 b1a1f0d6c57381f929f39ebaaafa38e569631db8 [ Upstream commit f4443293d741d1776b86ed1dd8c4e4285d0775fc ] When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy, the allocated pi->u.pi_lcnphy is leaked, since struct brcms_phy will be freed in the caller function. Fix this by calling wlc_phy_detach_lcnphy in the error handler of wlc_phy_txpwr_srom_read_lcnphy before returning. Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200908121743.23108-1-keitasuzuki.park@sslab.ics.keio.ac.jp Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f4443293d741d1776b86ed1dd8c4e4285d0775fc ]

When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy,
the allocated pi->u.pi_lcnphy is leaked, since struct brcms_phy will be
freed in the caller function.

Fix this by calling wlc_phy_detach_lcnphy in the error handler of
wlc_phy_txpwr_srom_read_lcnphy before returning.

Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200908121743.23108-1-keitasuzuki.park@sslab.ics.keio.ac.jp
Signed-off-by: Sasha Levin <sashal@kernel.org>
brcmfmac: To fix Bss Info flag definition Bug 2020-08-21T09:01:58+00:00 Prasanna Kerekoppa prasanna.kerekoppa@cypress.com 2020-06-04T07:18:35+00:00 0984f86d0b3599b41020bbee4cd1c09cc9e05823 [ Upstream commit fa3266541b13f390eb35bdbc38ff4a03368be004 ] Bss info flag definition need to be fixed from 0x2 to 0x4 This flag is for rssi info received on channel. All Firmware branches defined as 0x4 and this is bug in brcmfmac. Signed-off-by: Prasanna Kerekoppa <prasanna.kerekoppa@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200604071835.3842-6-wright.feng@cypress.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit fa3266541b13f390eb35bdbc38ff4a03368be004 ]

Bss info flag definition need to be fixed from 0x2 to 0x4
This flag is for rssi info received on channel.
All Firmware branches defined as 0x4 and this is bug in brcmfmac.

Signed-off-by: Prasanna Kerekoppa <prasanna.kerekoppa@cypress.com>
Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Wright Feng <wright.feng@cypress.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200604071835.3842-6-wright.feng@cypress.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
b43_legacy: Fix connection problem with WPA3 2020-06-20T08:24:20+00:00 Larry Finger Larry.Finger@lwfinger.net 2020-05-26T15:59:09+00:00 f67f751870f11b4b2b394c4c50840279b07e80c4 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 <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200526155909.5807-3-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200526155909.5807-3-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
b43: Fix connection problem with WPA3 2020-06-20T08:24:20+00:00 Larry Finger Larry.Finger@lwfinger.net 2020-05-26T15:59:08+00:00 4646d0032969575499c374bd2fe7798227385fcd 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 <rsalvaterra@gmail.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200526155909.5807-2-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <rsalvaterra@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200526155909.5807-2-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
b43legacy: Fix case where channel status is corrupted 2020-06-20T08:24:20+00:00 Larry Finger Larry.Finger@lwfinger.net 2020-04-07T19:00:43+00:00 7581e7d31ebdc911f7fa76ddf99c89a97e06f88d 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 <stable@vger.kernel.org> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-and-tested by: F. Erhard <erhard_f@mailbox.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200407190043.1686-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <stable@vger.kernel.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-and-tested by: F. Erhard <erhard_f@mailbox.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200407190043.1686-1-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>