- 24 May, 2017 15 commits
-
-
Kees Cook authored
Using memcpy() from a string that is shorter than the length copied means the destination buffer is being filled with arbitrary data from the kernel rodata segment. Instead, redefine the stat strings to be ETH_GSTRING_LEN sizes, like other drivers. This lets us use a single memcpy that does not leak rodata contents. Additionally adjust indentation to keep checkpatch.pl happy. This was found with the future CONFIG_FORTIFY_SOURCE feature. Cc: Daniel Micay <danielmicay@gmail.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Stanislaw Gruszka authored
iwlegacy firmware can crash when power save is configured. PS was allowed in "dbdac2b5 iwlegacy: properly enable power saving" with belive that user who enable PS is aware of that and can relate firmware crahes with PS. However some distributions seems to enable PS without user intervention, so warn about that. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
In the stable linux-3.16 branch, I ran into a warning in the wlcore driver: drivers/net/wireless/ti/wlcore/spi.c: In function 'wl12xx_spi_raw_write': drivers/net/wireless/ti/wlcore/spi.c:315:1: error: the frame size of 12848 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Newer kernels no longer show the warning, but the bug is still there, as the allocation is based on the CPU page size rather than the actual capabilities of the hardware. This replaces the PAGE_SIZE macro with the SZ_4K macro, i.e. 4096 bytes per buffer. Cc: stable@vger.kernel.org Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Karim Eshapa authored
Use time_after kernel macro for time comparison. Signed-off-by:
Karim Eshapa <karim.eshapa@gmail.com> Signed-off-by:
-
Prameela Rani Garnepudi authored
The older firmware loading method is not usable by any Redpine chipset. Hence removing that part of the code. Older firmware image with rsi_91x.fw name is deprecated Signed-off-by:
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by:
Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by:
-
Prameela Rani Garnepudi authored
The older firmware loading method has been deprecated and not in use for any chipets. New method is introduced which works based on soft boot loader. In this method, complete RAM image and FLASH image are present in the flash. Before loading the functional firmware, host issues boot loader commands to verify whether firmware to load is different from the current functional firmware. If not, firmware upgrade progresses and boot loader will switch to the new functional firmware. "rs9113_wlan_qspi.rps" is the firmware filename used in this patch. Signed-off-by:
-
Prameela Rani Garnepudi authored
Host interface opearation master_reg_read, master_reg_write and load_data_master_write are added. These functions are needed for the new firmware loading method. As part of this, the function master_access_msword is moved from rsi_91x_sdio_ops.c to rsi_91x_sdio.c. Signed-off-by:
-
Prameela Rani Garnepudi authored
Host interface operations are currently function pointers in rsi_hw structure. As more host interface operations are going to be introduced, separate structure is added for these for convenience. Signed-off-by:
-
Prameela Rani Garnepudi authored
USB multibyte read will be used in the new firmware loading method for RS9113 chipset. Signed-off-by:
-
Prameela Rani Garnepudi authored
In function usb_write_register_multiple, if any intermediate block transfer is failed, further operations should be terminated. 'else' is removed, as there is no significance for it after return. Signed-off-by:
-
Prameela Rani Garnepudi authored
For USB vendor read and write operations new macros added to avoid redundant usage of long or'ed macros. Also for timeouts standard USB macros are used. Signed-off-by:
-
Prameela Rani Garnepudi authored
USB read and write registers maximum size is limited 2^16. More than this size is not used in the driver. Signed-off-by:
-
amit karwar authored
RSI_USB_BUF_SIZE macro is used instead of hardcoding a buffer size to 4096. Signed-off-by:
-
Prameela Rani Garnepudi authored
SDIO read or write maximum size is limited to 2^16. This is done to make the host interface operations common for SDIO and USB. Signed-off-by:
-
Prameela Rani Garnepudi authored
The file rsi_91x_hal.c is going to contain device specific code i.e new firmware loading method for RS9113 chipset. As the file rsi_91x_pkt.c contains code to prepare device specific descriptors for transmit packet, this file is renamed to rsi_91x_hal.c which is more relevant as per it's functionality. Signed-off-by:
-
- 22 May, 2017 7 commits
-
-
Dan Carpenter authored
We have the number of longs, but we should be calculating the number of bytes needed. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Kees Cook authored
Using memcpy() from a buffer that is shorter than the length copied means the destination buffer is being filled with arbitrary data from the kernel rodata segment. In this case, the source was made longer, since it did not match the destination structure size. Additionally removes a needless cast. This was found with the future CONFIG_FORTIFY_SOURCE feature. Cc: Daniel Micay <danielmicay@gmail.com> Signed-off-by:
-
Elena Reshetova authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
Elena Reshetova <elena.reshetova@intel.com> Signed-off-by:
Hans Liljestrand <ishkamiel@gmail.com> Signed-off-by:
David Windsor <dwindsor@gmail.com> Signed-off-by:
-
Elena Reshetova authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Chi-hsien Lin authored
Upon stopping an AP interface the driver disable INFRA mode effectively setting the interface in IBSS mode. However, this may affect other interfaces running in INFRA mode. For instance, if user creates and stops hostap daemon on virtual interface, then association cannot work on primary interface because default BSS has been set to IBSS mode in firmware side. The IBSS mode should be set when cfg80211 changes the interface. Reviewed-by:
Wright Feng <wright.feng@cypress.com> Signed-off-by:
Chi-hsien Lin <Chi-Hsien.Lin@cypress.com> [kvalo@codeaurora.org: rephased commit log based on discussion] Signed-off-by:
-
Xie Qirong authored
setup_timer.cocci suggested the following improvement: drivers/net/wireless/broadcom/brcm80211/brcmfmac/btcoex.c:383:1-11: Use setup_timer function for function on line 384. The combination of init_timer and setting up the data and function field manually is equivalent to calling setup_timer(). This is an api consolidation only and improves readability. Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Xie Qirong <cheerx1994@gmail.com> Signed-off-by:
-
Takashi Iwai authored
Some firmware entries were forgotten to be added via MODULE_FIRMWARE(), which may result in the non-functional state when the driver is loaded in initrd. Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1037344 Fixes: 15be8e89 ("b43: add more bcma cores") Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
- 19 May, 2017 18 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for 4.13. Major changes: ath10k * add initial SDIO support (still work in progress)
-
Stanislaw Gruszka authored
When driver fail to reset card ah->curchan value stay NULL. When later driver try to update tx power it oops by using ah->curchan (calltrace is shown below). This problem were reported at various places and for some it was fixed by making ath9k_hw_chip_reset() do not fail. I have this bug report on some oldish RHEL kernel with AR9285, however it's hard to debug where reset fail when kernel OOPS, so I think this patch should be applied. Hopefully ah->curchan is not used unconditionally on other places until is initialized on ath9k_config(). ath: phy0: Chip reset failed ath: phy0: Unable to reset hardware; reset status -22 (freq 2412 MHz) BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<f8a35585>] ath9k_hw_set_txpowerlimit+0x25/0x80 [ath9k_hw] Oops: 0000 [#1] SMP <snip> Call Trace: [<f8aac1aa>] ? ath9k_cmn_update_txpow+0x1a/0x30 [ath9k_common] [<f8cf4f4e>] ? ath_complete_reset+0x4e/0x130 [ath9k] [<f8cf54d7>] ? ath9k_start+0x127/0x1e0 [ath9k] [<f8c2e52f>] ? ieee80211_do_open+0x30f/0x910 [mac80211] [<c07bd96d>] ? dev_open+0x8d/0xf0 Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com>
-
Gustavo A. R. Silva authored
The array field eeprom_data in struct th9k_platform_data is a fixed size array so it can never be NULL. Addresses-Coverity-ID: 1364903 Cc: Arend Van Spriel <arend.vanspriel@broadcom.com> Cc: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
-
Geliang Tang authored
Use memdup_user() helper instead of open-coding to simplify the code. Signed-off-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
-
Colin Ian King authored
The AR5K_EEPROM_READ macro returns with -EIO if a read error occurs causing a memory leak on the allocated buffer buf. Fix this by explicitly calling ath5k_hw_nvram_read and exiting on the via the freebuf label that performs the necessary free'ing of buf when a read error occurs. Detected by CoverityScan, CID#1248782 ("Resource Leak") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Ammly Fredrick authored
It's spelled hardware, not harware. Signed-off-by:
Ammly Fredrick <ammlyf@gmail.com> [kvalo@qca.qualcomm.com: improve commit log] Signed-off-by:
-
Arend Van Spriel authored
An issue was found brcmfmac driver in which a skbuff in .start_xmit() callback was actually cloned. So instead of checking for sufficient headroom it should also be writable. Hence use skb_cow_head() to check and expand the headroom appropriately. Signed-off-by:
Steve deRosier <derosier@gmail.com> Signed-off-by:
-
Johan Hovold authored
Add the missing endianness conversions to a debug statement printing the USB device-descriptor bcdUSB field during probe. Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Brian Norris authored
These are already handled by mwifiex_shutdown_sw() and mwifiex_reinit_sw(). Ideally, we'll kill the flag entirely eventually, as I suspect it breeds race conditions. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Brian Norris authored
Signed-off-by:
-
Brian Norris authored
These pointers are retrieved via container_of(). There's no way they are NULL. Signed-off-by:
-
Brian Norris authored
We're using 'adapter' right before calling this. Stop being unnecessarily paranoid. Signed-off-by:
-
Brian Norris authored
If mwifiex_shutdown_drv() is racing with another mwifiex_shutdown_drv(), we *really* have problems. Kill the lock. Signed-off-by:
-
Brian Norris authored
When removing or resetting an mwifiex device, we don't remember to free the saved beacon buffer. Use the (somewhat misleadingly-named) mwifiex_free_priv() helper to handle this. Noticed by kmemleak during tests: echo 1 > /sys/bus/pci/devices/.../reset unreferenced object 0xffffffc09d034a00 (size 256): ... backtrace: [<ffffffc0003cdce4>] create_object+0x228/0x3c4 [<ffffffc000c0b9d8>] kmemleak_alloc+0x54/0x88 [<ffffffc0003c0848>] __kmalloc+0x1cc/0x2dc [<ffffffbffc1500c4>] mwifiex_save_curr_bcn+0x80/0x308 [mwifiex] [<ffffffbffc1516b8>] mwifiex_ret_802_11_associate+0x4ec/0x5fc [mwifiex] [<ffffffbffc15da90>] mwifiex_process_sta_cmdresp+0xaf8/0x1fa4 [mwifiex] [<ffffffbffc1411e0>] mwifiex_process_cmdresp+0x40c/0x510 [mwifiex] [<ffffffbffc13b8f4>] mwifiex_main_process+0x4a4/0xb00 [mwifiex] [<ffffffbffc13bf84>] mwifiex_main_work_queue+0x34/0x40 [mwifiex] Signed-off-by: -
Brian Norris authored
mwifiex_exec_next_cmd() seems to have a classic TOCTOU race, where we drop the list lock in between retrieving the next command and deleting it from the list. This potentially leaves room for someone else to also retrieve / steal this node from the list (e.g., mwifiex_cancel_all_pending_cmd()). Let's keep holding the lock while we do our 'ps_state' sanity checks. There should be no harm in continuing to hold this lock for a bit more. Noticed only by code inspection. Signed-off-by:
-
Douglas Anderson authored
The mwifiex_11n_delba() function walked the rx_reorder_tbl_ptr without holding the lock, which was an obvious violation. Grab the lock. NOTE: we hold the lock while calling mwifiex_send_delba(). There's also several callers in 11n_rxreorder.c that hold the lock and the comments in the struct sound just like very other list/lock pair -- as if the lock should definitely be help for all operations like this. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Douglas Anderson authored
Just like in the previous patch ("mwifiex: Don't release tx_ba_stream_tbl_lock while iterating"), in mwifiex_cancel_all_pending_cmd() we were itearting over a list protected by a spinlock. Again, it is not safe to release the spinlock while iterating. Don't do it. Luckily in this case there should be no need to release the spinlock. This is evidenced by: 1. The only function called while the spinlock was released was mwifiex_recycle_cmd_node() 2. Aside from atomic functions (which are safe to call), the only function called by mwifiex_recycle_cmd_node() was mwifiex_insert_cmd_to_free_q(). 3. It can be seen in mwifiex_cancel_pending_scan_cmd() that it's OK to call mwifiex_insert_cmd_to_free_q() while holding a different spinlock (scan_pending_q_lock), so in general holding a spinlock should be OK. 4. It doesn't appear that mwifiex_insert_cmd_to_free_q() has any interaction with the cmd_pending_q_lock No known bugs are fixed with this change, but as with other similar changes this could fix random list corruption. Signed-off-by: -
Douglas Anderson authored
Despite the macro list_for_each_entry_safe() having the word "safe" in the name, it's still not actually safe to release the list spinlock while iterating over the list. The "safe" in the macro name actually only means that it's safe to delete the current entry while iterating over the list. Releasing the spinlock while iterating over the list means that someone else could come in and adjust the list while we don't have the spinlock. If they do that it can totally mix up our iteration and fully corrupt the list. Later iterating over a corrupted list while holding a spinlock and having IRQs off can cause all sorts of hard to debug problems. As evidenced by the other call to mwifiex_11n_delete_tx_ba_stream_tbl_entry() in mwifiex_11n_delete_all_tx_ba_stream_tbl(), it's actually safe to skip the spinlock release. Let's do that. No known problems are fixed by this patch, but it could fix all sorts of weird problems and it should be very safe. Signed-off-by:
-
