Re: [PATCH] nl80211: Fix mesh HT operation check

On Thu, 2017-01-26 at 08:56 +0900, Masashi Honma wrote: > commit 9757235f451c27deaa88925399f070ff6fcea832 ('nl80211: correct > checks for NL80211_MESHCONF_HT_OPMODE value') missed to mask a flag > when replacing FILL_IN_MESH_PARAM_IF_SET with checking codes. This > could drop the received HT

Re: [PATCH] mac80211: Fix FILS AEAD protection in Association Request frame

On Sat, 2017-02-04 at 13:59 +0200, Jouni Malinen wrote: > Incorrect num_elem parameter value (1 vs. 5) was used in the > aes_siv_encrypt() call. This resulted in only the first one of the > five > AAD vectors to SIV getting included in calculation. This does not > protect all the contents

Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD

Hi, > The skcipher could have been of the async variant which may return > from skcipher_encrypt() with -EINPROGRESS after having queued the > request. > The FILS AEAD implementation here does not have code for dealing with > that possibility, so allocate a sync cipher explicitly to avoid >

Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

Hi Kalle, sorry for the delay On Wed, Jan 25, 2017 at 01:46:28PM +, Valo, Kalle wrote: > Kalle Valo writes: > > > Mohammed Shafi Shajakhan writes: > > > >> From: Mohammed Shafi Shajakhan > >> > >> This fixes

Re: Installing driver for Ubuntu 16.04 Intel(R) Wireless WiFi Link 4965AGN

On Sun, Feb 5, 2017 at 6:31 PM, Leopoldo wrote: > Dear Sedat, > > Did you have the chance to have a look to this? > No. If it was not clear said: I did not promise to look at it, I just said sent the logs and people here can look at it. - Sedat - > Kind regards. > >

Re: [PATCH V3 5/9] brcmfmac: pcie: store private pointer to struct brcmf_pub

On 2-2-2017 22:33, Rafał Miłecki wrote: > From: Rafał Miłecki > > Getting this pointer in PCIe code is not trivial and requires using > dev_get_drvdata helper which adds extra line of code. Having access to > this struct is useful for using generic stuff and e.g. improving

Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"

On 05.02.2017 20:30, Larry Finger wrote: > On 02/05/2017 05:34 AM, Dmitry Osipenko wrote: >> BTW, I have an issue with the 8192cu: WiFi stops to work after a while (3-15 >> minutes) if I enable WMM QoS on the AP. There is nothing suspicious in KMSG, >> connection is up but no packets go in/out. I

Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"

On 02/05/2017 05:34 AM, Dmitry Osipenko wrote: BTW, I have an issue with the 8192cu: WiFi stops to work after a while (3-15 minutes) if I enable WMM QoS on the AP. There is nothing suspicious in KMSG, connection is up but no packets go in/out. I tried to enable debug messages in the driver, so

[PATCH] rtlwifi: rtl8192c-common: Fix "BUG: KASAN:

Kernels built with CONFIG_KASAN=y report the following BUG for rtl8192cu and rtl8192c-common: == BUG: KASAN: slab-out-of-bounds in rtl92c_dm_bt_coexist+0x858/0x1e40 [rtl8192c_common] at addr 8801c90edb08 Read of size 1 by

[PATCH v2 2/2] mac80211: aes-cmac: switch to shash CMAC driver

Instead of open coding the CMAC algorithm in the mac80211 driver using byte wide xors and calls into the crypto layer for each block of data, instantiate a cmac(aes) synchronous hash and pass all the data into it directly. This does not only simplify the code, it also allows the use of more

[PATCH v2 0/2] mac80211: use crypto shash for AES cmac

This is something I spotted while working on AES in various modes for ARM and arm64. The mac80211 aes_cmac code reimplements the CMAC algorithm based on the core AES cipher, which is rather restrictive in how platforms can satisfy the dependency on this algorithm. For instance, SIMD

[PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

Switch the FILS AEAD code to use a cmac(aes) shash instantiated by the crypto API rather than reusing the open coded implementation in aes_cmac_vector(). This makes the code more understandable, and allows platforms to implement cmac(aes) in a more secure (*) and efficient way than is typically

Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"

On 05.02.2017 04:05, Larry Finger wrote: > On 02/04/2017 01:32 PM, Dmitry Osipenko wrote: >> On 04.02.2017 21:41, Larry Finger wrote: >>> On 02/04/2017 10:58 AM, Dmitry Osipenko wrote: Seems the problem is caused by rtl92c_dm_*() casting .priv to "struct rtl_pci_priv", while it is