[PATCH] ath10k: fix use-after-free in ath10k_wmi_cmd_send_nowait

The skb may be freed in tx completion context before trace_ath10k_wmi_cmd is called. This can be easily captured when KASAN(Kernel Address Sanitizer) is enabled. The fix is to add a reference count to the skb and release it after trace_ath10k_wmi_cmd is called. Signed-off-by: Carl Huang --- driv

[PATCH] ath10k: fix use-after-free in ath10k_wmi_cmd_send_nowait

The skb may be freed in tx completion context before trace_ath10k_wmi_cmd is called. This can be easily captured when KASAN(Kernel Address Sanitizer) is enabled. The fix is to add a reference count to the skb and release it after trace_ath10k_wmi_cmd is called. Signed-off-by: Carl Huang --- driv

Re: Regulatory: reg.c : wiphy_apply_custom_regulatory()

> Can wiphy_apply_custom_regulatory() be called after wiphy registeration? > The documentation(comment) says "/* Used by drivers prior to wiphy > registration */" > Whys is there a restriction to call this after registration? Is the > comment outdated? After Tracing the regulatory code in the cfg8

Re: mac80211 scan results, signal value not reliable

On Thu, 2018-02-08 at 09:49 +, Jean Pierre TOSONI wrote: > In net/mac80211/scan.c, function ieee80211_bss_info_update() passes > incoming scan results to the generic wireless layer, with indication of > the received signal level, but no indication of signal validity. Well, there is an indicat

Re: [PATCH v2] ieee80211: Increase the PMK maximum length to 64 bytes

On Sat, 2018-02-10 at 12:32 +0200, Jouni Malinen wrote: > > > Yeah I'm concerned about this too - and regardless of that issue, we > > probably need those drivers that do support it to advertise support for > > the new curves, and then allow the longer PMK length only for those that do? > > Pleas

Re: [PATCH] ath9k: turn on btcoex_enable as default

On 2018-02-10 14:56, Kai Heng Feng wrote: > >> On 9 Feb 2018, at 3:16 PM, Kalle Valo wrote: >> Sure, but we have to make sure that we don't create regressions on >> existing systems. For example, did you test this with any system which >> don't support btcoex? (just asking, haven't tested this my

[PATCH v2 3/4] qtnfmac: implement asynchronous firmware loading

In pci probe() function start firmware loading, protocol handshake and driver core initialization, and not wait for completion. Signed-off-by: Sergei Maksimenko --- drivers/net/wireless/quantenna/qtnfmac/bus.h | 3 +- .../net/wireless/quantenna/qtnfmac/pearl/pcie.c| 375 ++---

[PATCH v2 1/4] qtnfmac: fix releasing Tx/Rx data buffers

Add missing PCI unmap for Tx buffers and release all buffers explicitly. Managed release using devm_add_action is not suitable for qtnfmac Tx/Rx data buffers. The reason is in ordering and dependencies: buffers should be released after transmission is stopped but before PCI device resources and DMA

[PATCH v2 2/4] qtnfmac: enable reloading of qtnfmac kernel modules

From: Sergei Maksimenko This patch enables rmmod/insmod for qtnfmac kernel modules: - do not 'pin' pci device in order to disable it on module unload - implement card reset procedure - restore PCI bar addresses for restarted wireless card Signed-off-by: Sergei Maksimenko Signed-off-by: Sergey M

[PATCH v2 4/4] qtnfmac: enable networked standby mode on device inactivity

From: Sergei Maksimenko Enable support of networked standby mode (NSM) on qsr10g devices. Networked standby is a power saving mode when the device keeps all existing network connections and returns to full power mode on a network activity. When enabled, device enters standby mode after 15 min of

[PATCH v2 0/4] qtnfmac: qsr10g pcie backend updates

Hello Kalle and all, Here is a patch set with various fixes and enhacements for qsr10g PCIe backend driver. The major changes include the following two items: - make rmmod/insmod work properly for qtnfmac_pcie driver - provide configuration knobs to control NSM (networked standby mode) NSM (netwo

Re: [PATCH] ath9k: turn on btcoex_enable as default

> On 9 Feb 2018, at 3:16 PM, Kalle Valo wrote: > Sure, but we have to make sure that we don't create regressions on > existing systems. For example, did you test this with any system which > don't support btcoex? (just asking, haven't tested this myself) No not really, but I will definitely test

[PATCH v2] mac80211: round IEEE80211_TX_STATUS_HEADROOM up to multiple of 4

This ensures that mac80211 allocated management frames are properly aligned, which makes copying them more efficient. For instance, mt76 uses iowrite32_copy to copy beacon frames to beacon template memory on the chip. Misaligned 32-bit accesses cause CPU exceptions on MIPS and should be avoided. S

Re: [PATCH v2] ieee80211: Increase the PMK maximum length to 64 bytes

On Wed, Feb 07, 2018 at 09:21:34PM +0100, Johannes Berg wrote: > On Wed, 2018-02-07 at 20:35 +0100, Arend van Spriel wrote: > > On 2/7/2018 5:20 PM, Srinivas Dasari wrote: > > > This is needed to cover the case of DPP with the NIST P-521 and > > > brainpoolP512r1 curves which derive a PMK that is l