Re: [PATCH] ath9k: fix tx99 potential info leak

>> >> +buf[len] = '\0'; >> + > > I think it would be more appropriate here to check if buf[len] == '\0' and > return an error otherwise. Nevermind, I just had a closer look and I actually think your approach is fine. I hadn't considered the possibility of someone deliberately passing a

Re: [PATCH] ath9k: fix tx99 potential info leak

Am 27. September 2017 03:13:34 MESZ schrieb miaoq...@codeaurora.org: >From: Miaoqing Pan > >When the user sets count to zero the string buffer would remain >completely uninitialized which causes the kernel to parse its >own stack data, potentially leading to an info leak.

Re: pull-request: wireless-drivers 2017-09-25

From: Kalle Valo Date: Mon, 25 Sep 2017 11:55:22 +0300 > here a pull request to net for 4.14, more info in the signed tag below. > Please let me know if there are any problems. Pulled, thanks Kalle.

[PATCH] ath9k: fix tx99 potential info leak

From: Miaoqing Pan When the user sets count to zero the string buffer would remain completely uninitialized which causes the kernel to parse its own stack data, potentially leading to an info leak. In addition to that, the string might be not terminated properly when the

Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation

Hi Daniel, [auto build test ERROR on pci/next] [also build test ERROR on v4.14-rc2] [cannot apply to tip/x86/core next-20170926] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Daniel-Drake/PCI

[PATCH] ath10k: Retry pci probe on failure.

From: Ben Greear This works around a problem we see when sometimes the wifi NIC does not respond the first time. This seems to happen especially often on some of the 9984 NICs in mid-range platforms. Signed-off-by: Ben Greear ---

Re: [PATCH] wireless-regdb: Update regulatory rules for Singapore (SG)

On Thu, Aug 24, 2017 at 11:17:44AM -0500, Seth Forshee wrote: > On Thu, Aug 24, 2017 at 09:13:42AM +0200, Sven Eckelmann wrote: > > On Mittwoch, 23. August 2017 15:52:40 CEST Seth Forshee wrote: > > [...] > > > > +# Source > > > > +# > > > >

Re: [PATCH v4 9/9] kasan: rework Kconfig settings

On 09/23/2017 12:29 AM, Arnd Bergmann wrote: > We get a lot of very large stack frames using gcc-7.0.1 with the default > -fsanitize-address-use-after-scope --param asan-stack=1 options, which > can easily cause an overflow of the kernel stack, e.g. > > drivers/gpu/drm/i915/gvt/handlers.c:2407:1:

Re: [PATCH v2] iwlwifi: mvm: allow monitor mode capture in STA mode

Hi Luciano, Thanks for the update. I was hoping that it would be supported since I remember that iwldvm had no problem with it in the past. Best, Gavin On Tue, Sep 26, 2017 at 12:59 AM, Coelho, Luciano wrote: > Hi Gavin, > > On Thu, 2017-09-14 at 22:11 -0700,

Re: [PATCH v2] p54: don't unregister leds when they are not initialized

On Tuesday, September 26, 2017 5:11:33 PM CEST Andrey Konovalov wrote: > ieee80211_register_hw() in p54_register_common() may fail and leds won't > get initialized. Currently p54_unregister_common() doesn't check that and > always calls p54_unregister_leds(). The fix is to check priv->registered >

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On 09/26/2017 09:47 AM, Arnd Bergmann wrote: > On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote: >> On Mon, Sep 25, 2017 at 7:41 AM, David Laight >> wrote: >>> From: Arnd Bergmann Sent: 22 September 2017 22:29 >>> ... It seems that this

[PATCH v2] p54: don't unregister leds when they are not initialized

ieee80211_register_hw() in p54_register_common() may fail and leds won't get initialized. Currently p54_unregister_common() doesn't check that and always calls p54_unregister_leds(). The fix is to check priv->registered flag before calling p54_unregister_leds(). Found by syzkaller. INFO: trying

Re: [PATCH] p54: don't unregister leds when they are inited

On Tue, Sep 26, 2017 at 5:08 PM, Johannes Berg wrote: > Subject should say *not* initialized? Yes, sent v2. > > johannes

Re: [PATCH] p54: don't unregister leds when they are inited

Subject should say *not* initialized? johannes

[PATCH] p54: don't unregister leds when they are inited

ieee80211_register_hw() in p54_register_common() may fail and leds won't get initialized. Currently p54_unregister_common() doesn't check that and always calls p54_unregister_leds(). The fix is to check priv->registered flag before calling p54_unregister_leds(). Found by syzkaller. INFO: trying

Re: [RESEND] Re: usb/net/p54: trying to register non-static key in p54_unregister_leds

On Sat, Sep 23, 2017 at 9:37 PM, 'Christian Lamparter' via syzkaller wrote: > This got rejected by gmail once. Let's see if it works now. > > On Thursday, September 21, 2017 8:22:45 PM CEST Andrey Konovalov wrote: >> On Wed, Sep 20, 2017 at 9:55 PM, Johannes Berg >>

Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically

On Tue, Sep 26, 2017 at 03:26:51PM +0800, AceLan Kao wrote: > Ath9k is an old driver for old chips, and they work fine with legacy INTx. > But some new platforms are using it, so I think we should list those > new platforms which blocks INTx in the driver. And unless they are broken and need a

[PATCH] mac80211: aead api to reduce redundancy

Currently, the aes_ccm.c and aes_gcm.c are almost line by line copy of each other. This patch reduce code redundancy by moving the code in these two files to crypto/aead_api.c to make it a higher level aead api. The file aes_ccm.c and aes_gcm.c are removed and all the functions there are now

Re: [1/7] brcmfmac: handle FWHALT mailbox indication

On 26 September 2017 at 12:11, Arend van Spriel wrote: > On 25-09-17 11:30, James Hughes wrote: >> >> On 25 September 2017 at 10:26, James Hughes >> wrote: >>> >>> On 25 September 2017 at 09:18, Kalle Valo wrote:

[PATCH v2] mac80211: fix STA_SLOW_THRESHOLD htmldocs failure

Patch fixes htmldocs build problem: Error(.//net/mac80211/sta_info.h:416): cannot understand prototype: 'STA_SLOW_THRESHOLD 6000 ' Signed-off-by: Stanislaw Gruszka --- v1 -> v2: just fix documentation build, do not move the code. net/mac80211/sta_info.h |2 +- 1

Re: [PATCH] mac80211: make STA_SLOW_THRESHOLD local

On Tue, Sep 26, 2017 at 12:18:14PM +0200, Johannes Berg wrote: > On Tue, 2017-09-26 at 11:59 +0200, Stanislaw Gruszka wrote: > > STA_SLOW_THRESHOLD is used only in one function, so don't need to be > > global define. > > > > Patch also fixes problem of htmldocs build I encountered: > > > >

Re: [1/7] brcmfmac: handle FWHALT mailbox indication

On 25-09-17 11:30, James Hughes wrote: On 25 September 2017 at 10:26, James Hughes wrote: On 25 September 2017 at 09:18, Kalle Valo wrote: Arend Van Spriel wrote: The firmware uses a mailbox to communicate

Re: [PATCH] mac80211: make STA_SLOW_THRESHOLD local

On Tue, 2017-09-26 at 11:59 +0200, Stanislaw Gruszka wrote: > STA_SLOW_THRESHOLD is used only in one function, so don't need to be > global define. > > Patch also fixes problem of htmldocs build I encountered: > > Error(.//net/mac80211/sta_info.h:416): cannot understand prototype: >

[PATCH] mac80211: make STA_SLOW_THRESHOLD local

STA_SLOW_THRESHOLD is used only in one function, so don't need to be global define. Patch also fixes problem of htmldocs build I encountered: Error(.//net/mac80211/sta_info.h:416): cannot understand prototype: 'STA_SLOW_THRESHOLD 6000 ' Signed-off-by: Stanislaw Gruszka

Re: [PATCH 1/3] rsi: sdio: add WOWLAN support for S3 suspend state

Amitkumar Karwar writes: > From: Karun Eagalapati > > WoWLAN is supported in RS9113 device through GPIO pin2. > wowlan config frame is internally sent to firmware in mac80211 > suspend handler. Also beacon miss threshold and keep-alive time > values are

Re: [PATCH 2/3] rsi: sdio: Add WOWLAN support for S4 hibernate state

Amitkumar Karwar writes: > From: Karun Eagalapati > > We are disabling of interrupts from firmware in freeze handler. > Also setting power management capability KEEP_MMC_POWER to make > device wakeup for WoWLAN trigger. > At restore, we observed a

Re: [PATCH v2] iwlwifi: mvm: allow monitor mode capture in STA mode

Hi Gavin, On Thu, 2017-09-14 at 22:11 -0700, gavi...@thegavinli.com wrote: > From: Gavin Li > > Open up the filter if there is a monitor interface configured; this > allows all packets on the channel to be captured even if the device is > in STA mode and associated to a BSS.

Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically

Ath9k is an old driver for old chips, and they work fine with legacy INTx. But some new platforms are using it, so I think we should list those new platforms which blocks INTx in the driver. BTW, new chips use ath10k driver. 2017-09-26 14:44 GMT+08:00 Christoph Hellwig : > On

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote: > On Mon, Sep 25, 2017 at 7:41 AM, David Laight wrote: >> From: Arnd Bergmann >>> Sent: 22 September 2017 22:29 >> ... >>> It seems that this is triggered in part by using strlcpy(), which the >>>

Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically

On Tue, Sep 26, 2017 at 02:41:35PM +0800, AceLan Kao wrote: > Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI > for WLAN device. So adding a quirk to list those machines and set > use_msi automatically. > Adding Dell Inspiron 24-3460 to the quirk. Huh? Using MSI should

[PATCH 1/6] ath9k: add MSI support and use_msi parameter

Adding MSI support for ath9k devices. This patch is originally from Qualcomm, but they have no intention of submitting and maintaining ath9k driver now. The credit should go to Qualcomm. Signed-off-by: AceLan Kao --- drivers/net/wireless/ath/ath9k/hw.c | 33

[PATCH 2/6] ath9k: add a quirk to set use_msi automatically

Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI for WLAN device. So adding a quirk to list those machines and set use_msi automatically. Adding Dell Inspiron 24-3460 to the quirk. Signed-off-by: AceLan Kao ---

[PATCH 6/6] ath9k: set use_msi=1 on Dell Inspiron 14-3473

BIOS on Dell Inspiron 14-3473 blocks legacy interrupts (INTx), and only allows MSI for WLAN device. Signed-off-by: AceLan Kao --- drivers/net/wireless/ath/ath9k/init.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/init.c

[PATCH 4/6] ath9k: set use_msi=1 on Dell Inspiron 3472

BIOS on Dell Inspiron 3472 blocks legacy interrupts (INTx), and only allows MSI for WLAN device. Signed-off-by: AceLan Kao --- drivers/net/wireless/ath/ath9k/init.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/init.c

[PATCH 3/6] ath9k: set use_msi=1 on Dell Vostro 3262

BIOS on Dell Vostro 3262 blocks legacy interrupts (INTx), and only allows MSI for WLAN device. Signed-off-by: AceLan Kao --- drivers/net/wireless/ath/ath9k/init.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/init.c

[PATCH 5/6] ath9k: set use_msi=1 on Dell Vostro 15-3572

BIOS on Dell Vostro 15-3572 blocks legacy interrupts (INTx), and only allows MSI for WLAN device. Signed-off-by: AceLan Kao --- drivers/net/wireless/ath/ath9k/init.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/init.c

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On Mon, Sep 25, 2017 at 7:41 AM, David Laight wrote: > From: Arnd Bergmann >> Sent: 22 September 2017 22:29 > ... >> It seems that this is triggered in part by using strlcpy(), which the >> compiler doesn't recognize as copying at most 'len' bytes, since strlcpy >> is not