kernel.git/drivers/net/wireless/ath, branch linux-5.3.y

ar5523: check NULL before memcpy() in ar5523_cmd()

2019-12-17T19:07:48Z

commit 315cee426f87658a6799815845788fde965ddaad upstream. memcpy() call with "idata == NULL && ilen == 0" results in undefined behavior in ar5523_cmd(). For example, NULL is passed in callchain "ar5523_stat_work() -> ar5523_cmd_write() -> ar5523_cmd()". This patch adds ilen check before memcpy() call in ar5523_cmd() to prevent an undefined behavior. Cc: Pontus Fuchs Cc: Kalle Valo Cc: "David S. Miller" Cc: David Laight Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

wil6210: check len before memcpy() calls

2019-12-17T19:07:47Z

commit 2c840676be8ffc624bf9bb4490d944fd13c02d71 upstream. memcpy() in wmi_set_ie() and wmi_update_ft_ies() is called with src == NULL and len == 0. This is an undefined behavior. Fix it by checking "ie_len > 0" before the memcpy() calls. As suggested by GCC documentation: "The pointers passed to memmove (and similar functions in ) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call." [1] [1] https://gcc.gnu.org/gcc-4.9/porting_to.html Cc: Maya Erez Cc: Kalle Valo Cc: "David S. Miller" Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath9k_hw: fix uninitialized variable data

2019-11-29T09:07:55Z

commit 80e84f36412e0c5172447b6947068dca0d04ee82 upstream. Currently, data variable in ar9003_hw_thermo_cal_apply() could be uninitialized if ar9300_otp_read_word() will fail to read the value. Initialize data variable with 0 to prevent an undefined behavior. This will be enough to handle error case when ar9300_otp_read_word() fails. Fixes: 80fe43f2bbd5 ("ath9k_hw: Read and configure thermocal for AR9462") Cc: Rajkumar Manoharan Cc: John W. Linville Cc: Kalle Valo Cc: "David S. Miller" Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath10k: Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe

2019-11-29T09:07:54Z

commit bfd6e6e6c5d2ee43a3d9902b36e01fc7527ebb27 upstream. The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects are initialized to point to the containing `ath10k_usb` object according to endpoint descriptors read from the device side, as shown below in `ath10k_usb_setup_pipe_resources`: for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) { endpoint = &iface_desc->endpoint[i].desc; // get the address from endpoint descriptor pipe_num = ath10k_usb_get_logical_pipe_num(ar_usb, endpoint->bEndpointAddress, &urbcount); ...... // select the pipe object pipe = &ar_usb->pipes[pipe_num]; // initialize the ar_usb field pipe->ar_usb = ar_usb; } The driver assumes that the addresses reported in endpoint descriptors from device side to be complete. If a device is malicious and does not report complete addresses, it may trigger NULL-ptr-deref `ath10k_usb_alloc_urb_from_pipe` and `ath10k_usb_free_urb_to_pipe`. This patch fixes the bug by preventing potential NULL-ptr-deref. Signed-off-by: Hui Peng Reported-by: Hui Peng Reported-by: Mathias Payer Reviewed-by: Greg Kroah-Hartman [groeck: Add driver tag to subject, fix build warning] Signed-off-by: Guenter Roeck Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath10k: Fix HOST capability QMI incompatibility

2019-11-29T09:07:54Z

commit 7165ef890a4c44cf16db66b82fd78448f4bde6ba upstream. The introduction of 768ec4c012ac ("ath10k: update HOST capability QMI message") served the purpose of supporting the new and extended HOST capability QMI message. But while the new message adds a slew of optional members it changes the data type of the "daemon_support" member, which means that older versions of the firmware will fail to decode the incoming request message. There is no way to detect this breakage from Linux and there's no way to recover from sending the wrong message (i.e. we can't just try one format and then fallback to the other), so a quirk is introduced in DeviceTree to indicate to the driver that the firmware requires the 8bit version of this message. Cc: stable@vger.kernel.org Fixes: 768ec4c012ac ("ath10k: update HOST capability qmi message") Signed-off-by: Bjorn Andersson Acked-by: Rob Herring Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath10k: restore QCA9880-AR1A (v1) detection

2019-11-29T09:07:53Z

commit f8914a14623a79b73f72b2b1ee4cd9b2cb91b735 upstream. This patch restores the old behavior that read the chip_id on the QCA988x before resetting the chip. This needs to be done in this order since the unsupported QCA988x AR1A chips fall off the bus when resetted. Otherwise the next MMIO Op after the reset causes a BUS ERROR and panic. Cc: stable@vger.kernel.org Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in probe") Signed-off-by: Christian Lamparter Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath10k: fix latency issue for QCA988x

2019-11-06T12:08:58Z

commit d79749f7716d9dc32fa2d5075f6ec29aac63c76d upstream. (kvalo: cherry picked from commit 1340cc631bd00431e2f174525c971f119df9efa1 in wireless-drivers-next to wireless-drivers as this a frequently reported regression) Bad latency is found on QCA988x, the issue was introduced by commit 4504f0e5b571 ("ath10k: sdio: workaround firmware UART pin configuration bug"). If uart_pin_workaround is false, this change will set uart pin even if uart_print is false. Tested HW: QCA9880 Tested FW: 10.2.4-1.0-00037 Fixes: 4504f0e5b571 ("ath10k: sdio: workaround firmware UART pin configuration bug") Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath6kl: fix a NULL-ptr-deref bug in ath6kl_usb_alloc_urb_from_pipe()

2019-11-06T12:08:53Z

[ Upstream commit 39d170b3cb62ba98567f5c4f40c27b5864b304e5 ] The `ar_usb` field of `ath6kl_usb_pipe_usb_pipe` objects are initialized to point to the containing `ath6kl_usb` object according to endpoint descriptors read from the device side, as shown below in `ath6kl_usb_setup_pipe_resources`: for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) { endpoint = &iface_desc->endpoint[i].desc; // get the address from endpoint descriptor pipe_num = ath6kl_usb_get_logical_pipe_num(ar_usb, endpoint->bEndpointAddress, &urbcount); ...... // select the pipe object pipe = &ar_usb->pipes[pipe_num]; // initialize the ar_usb field pipe->ar_usb = ar_usb; } The driver assumes that the addresses reported in endpoint descriptors from device side to be complete. If a device is malicious and does not report complete addresses, it may trigger NULL-ptr-deref `ath6kl_usb_alloc_urb_from_pipe` and `ath6kl_usb_free_urb_to_pipe`. This patch fixes the bug by preventing potential NULL-ptr-deref (CVE-2019-15098). Signed-off-by: Hui Peng Reported-by: Hui Peng Reported-by: Mathias Payer Reviewed-by: Greg Kroah-Hartman Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

ath10k: fix channel info parsing for non tlv target

2019-10-05T13:12:29Z

commit 6be6c04bcc2e8770b8637632789ff15765124894 upstream. The tlv targets such as WCN3990 send more data in the chan info event, which is not sent by the non tlv targets. There is a minimum size check in the wmi event for non-tlv targets and hence we cannot update the common channel info structure as it was done in commit 13104929d2ec ("ath10k: fill the channel survey results for WCN3990 correctly"). This broke channel survey results on 10.x firmware versions. If the common channel info structure is updated, the size check for chan info event for non-tlv targets will fail and return -EPROTO and we see the below error messages ath10k_pci 0000:01:00.0: failed to parse chan info event: -71 Add tlv specific channel info structure and restore the original size of the common channel info structure to mitigate this issue. Tested HW: WCN3990 QCA9887 Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 10.2.4-1.0-00037 Fixes: 13104929d2ec ("ath10k: fill the channel survey results for WCN3990 correctly") Cc: stable@vger.kernel.org # 5.0 Signed-off-by: Rakesh Pillai Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

wireless: fix nl80211 vendor commands

2019-07-20T19:37:26Z

In my previous commit to validate a policy I neglected to actually add one to the few drivers using vendor commands, fix that now. Reported-by: Tony Lindgren Tested-by: Tony Lindgren Fixes: 901bb9891855 ("nl80211: require and validate vendor command policy") Signed-off-by: Johannes Berg