- Linux-stable-mirror - lists.linaro.org

[PATCH] mac80211_hwsim: fix use-after-free bug in hwsim_exit_net

by Benjamin Beichler

commit 8cfd36a0b53aeb4ec21d81eb79706697b84dfc3d upstream. When destroying a net namespace, all hwsim interfaces, which are not created in default namespace are deleted. But the async deletion of the interfaces could last longer than the actual destruction of the namespace, which results to an use after free bug. Therefore use synchronous deletion in this case. Fixes: 100cb9ff40e0 ("mac80211_hwsim: Allow managing radios from non-initial namespaces") Reported-by: syzbot+70ce058e01259de7bb1d(a)syzkaller.appspotmail.com Signed-off-by: Benjamin Beichler <benjamin.beichler(a)uni-rostock.de> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> --- This patch is prepared for linux-4.16.y branch drivers/net/wireless/mac80211_hwsim.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c index 35b21f8152bb..20af54378cc0 100644 --- a/drivers/net/wireless/mac80211_hwsim.c +++ b/drivers/net/wireless/mac80211_hwsim.c @@ -3484,8 +3484,11 @@ static void __net_exit hwsim_exit_net(struct net *net) list_del(&data->list); rhashtable_remove_fast(&hwsim_radios_rht, &data->rht, hwsim_rht_params); - INIT_WORK(&data->destroy_work, destroy_radio); - queue_work(hwsim_wq, &data->destroy_work); + spin_unlock_bh(&hwsim_radio_lock); + mac80211_hwsim_del_radio(data, + wiphy_name(data->hw->wiphy), + NULL); + spin_lock_bh(&hwsim_radio_lock); } spin_unlock_bh(&hwsim_radio_lock); } -- 2.17.0

7 years, 6 months

2
1
0 0

[PATCH 2/3] mtd: rawnand: marvell: fix CS pin count with old bindings

by Miquel Raynal

For both the old bindings and the new bindings the same logic was applied to retrieve the number of CS lines: using of_get_property() to get a size in bytes, converted in the actual number of lines by dividing it per sizeof(u32) (4 bytes). This is fine for the 'reg' property which is a list of the CS IDs but not for the 'num-cs' property which is directly the value of the number of CS. Anyway, no existing DT uses another value than 'num-cs = <1>' and no other value has ever been supported by the old driver (pxa3xx_nand.c). Remove this condition and apply a number of 1 CS anyway, as already described in the bindings. Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/marvell_nand.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c index 2a467c72bbfb..c33ebc2cc024 100644 --- a/drivers/mtd/nand/raw/marvell_nand.c +++ b/drivers/mtd/nand/raw/marvell_nand.c @@ -2299,29 +2299,23 @@ static int marvell_nand_chip_init(struct device *dev, struct marvell_nfc *nfc, /* * The legacy "num-cs" property indicates the number of CS on the only * chip connected to the controller (legacy bindings does not support - * more than one chip). CS are only incremented one by one while the RB - * pin is always the #0. + * more than one chip). The CS and RB pins are always the #0. * * When not using legacy bindings, a couple of "reg" and "nand-rb" * properties must be filled. For each chip, expressed as a subnode, * "reg" points to the CS lines and "nand-rb" to the RB line. */ - if (pdata) { + if (pdata || nfc->caps->legacy_of_bindings) { nsels = 1; - } else if (nfc->caps->legacy_of_bindings) { - if (!of_get_property(np, "num-cs", &nsels)) { - dev_err(dev, "missing num-cs property\n"); - return -EINVAL; - } } else { if (!of_get_property(np, "reg", &nsels)) { dev_err(dev, "missing reg property\n"); return -EINVAL; } - } - if (!pdata) nsels /= sizeof(u32); + } + if (!nsels) { dev_err(dev, "invalid reg property size\n"); return -EINVAL; -- 2.14.1

7 years, 6 months

1
0
0 0

[PATCH 1/3] mtd: rawnand: marvell: fix the chip-select DT parsing logic

by Miquel Raynal

The block responsible of parsing the DT for the number of chip-select lines uses an 'if/else if/else if' block. The content of the second and third 'else if' conditions are: 1/ the actual condition to enter the sub-block and 2/ the operation to do in this sub-block. [...] else if (condition1_to_enter && action1() == failed) raise_error(); else if (condition2_to_enter && action2() == failed) raise_error(); [...] In case of failure, the sub-block is entered and an error raised. Otherwise, in case of success, the code would continue erroneously in the next 'else if' statement because it did not failed (and did not enter the first 'else if' sub-block). The first 'else if' refers to legacy bindings while the second 'else if' refers to new bindings. The second 'else if', which is entered erroneously, checks for the 'reg' property, which, for old bindings, does not mean anything because it would not be the number of CS available, but the regular register map of almost any DT node. This being said, the content of the 'reg' property being the register map offset and length, it has '2' values, so the number of CS in this situation is assumed to be '2'. When running nand_scan_ident() with 2 CS, the core will check for an array of chips. It will first issue a RESET and then a READ_ID. Of course this will trigger two timeouts because there is no chip in front of the second CS: [ 1.367460] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000080) [ 1.474292] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000280) Indeed, this is harmless and the core will then assume there is only one valid CS. Fix the logic in the whole block by entering each sub-block just on the 'is legacy' condition, doing the action inside the sub-block. This way, when the action succeeds, the whole block is left. Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/marvell_nand.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c index 10e953218948..2a467c72bbfb 100644 --- a/drivers/mtd/nand/raw/marvell_nand.c +++ b/drivers/mtd/nand/raw/marvell_nand.c @@ -2308,13 +2308,16 @@ static int marvell_nand_chip_init(struct device *dev, struct marvell_nfc *nfc, */ if (pdata) { nsels = 1; - } else if (nfc->caps->legacy_of_bindings && - !of_get_property(np, "num-cs", &nsels)) { - dev_err(dev, "missing num-cs property\n"); - return -EINVAL; - } else if (!of_get_property(np, "reg", &nsels)) { - dev_err(dev, "missing reg property\n"); - return -EINVAL; + } else if (nfc->caps->legacy_of_bindings) { + if (!of_get_property(np, "num-cs", &nsels)) { + dev_err(dev, "missing num-cs property\n"); + return -EINVAL; + } + } else { + if (!of_get_property(np, "reg", &nsels)) { + dev_err(dev, "missing reg property\n"); + return -EINVAL; + } } if (!pdata) -- 2.14.1

7 years, 6 months

1
0
0 0

[PATCH] serial: 8250_early: Setup divider when uartclk is passed

by Michal Simek

device->baud is always non zero value because it is checked already in early_serial8250_setup() before init_port is called. Fixes: 0ff3ab701963 ("serial: 8250_early: Only set divisor if valid clk & baud") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- drivers/tty/serial/8250/8250_early.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_early.c b/drivers/tty/serial/8250/8250_early.c index ae6a256524d8..5cd8c36c8fcc 100644 --- a/drivers/tty/serial/8250/8250_early.c +++ b/drivers/tty/serial/8250/8250_early.c @@ -122,7 +122,7 @@ static void __init init_port(struct earlycon_device *device) serial8250_early_out(port, UART_FCR, 0); /* no fifo */ serial8250_early_out(port, UART_MCR, 0x3); /* DTR + RTS */ - if (port->uartclk && device->baud) { + if (port->uartclk) { divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud); c = serial8250_early_in(port, UART_LCR); serial8250_early_out(port, UART_LCR, c | UART_LCR_DLAB); -- 2.17.0

7 years, 6 months

3
3
0 0

patch "usb: do not reset if a low-speed or full-speed device timed out" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: do not reset if a low-speed or full-speed device timed out to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From 6e01827ed93947895680fbdad68c072a0f4e2450 Mon Sep 17 00:00:00 2001 From: Maxim Moseychuk <franchesko.salias.hudro.pedros(a)gmail.com> Date: Thu, 4 Jan 2018 21:43:03 +0300 Subject: usb: do not reset if a low-speed or full-speed device timed out Some low-speed and full-speed devices (for example, bluetooth) do not have time to initialize. For them, ETIMEDOUT is a valid error. We need to give them another try. Otherwise, they will never be initialized correctly and in dmesg will be messages "Bluetooth: hci0 command 0x1002 tx timeout" or similars. Fixes: 264904ccc33c ("usb: retry reset if a device times out") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Maxim Moseychuk <franchesko.salias.hudro.pedros(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/hub.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 92378594a86e..a86591772352 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -4555,7 +4555,9 @@ hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1, * reset. But only on the first attempt, * lest we get into a time out/reset loop */ - if (r == 0 || (r == -ETIMEDOUT && retries == 0)) + if (r == 0 || (r == -ETIMEDOUT && + retries == 0 && + udev->speed > USB_SPEED_FULL)) break; } udev->descriptor.bMaxPacketSize0 = -- 2.17.0

7 years, 6 months

1
0
0 0

FAILED: patch "[PATCH] tpm: self test failure should not cause suspend to fail" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 0803d7befa15cab5717d667a97a66214d2a4c083 Mon Sep 17 00:00:00 2001 From: Chris Chiu <chiu(a)endlessm.com> Date: Tue, 20 Mar 2018 15:36:40 +0800 Subject: [PATCH] tpm: self test failure should not cause suspend to fail The Acer Acer Veriton X4110G has a TPM device detected as: tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71) After the first S3 suspend, the following error appears during resume: tpm tpm0: A TPM error(38) occurred continue selftest Any following S3 suspend attempts will now fail with this error: tpm tpm0: Error (38) sending savestate before suspend PM: Device 00:0b failed to suspend: error 38 Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is not in the correct state. This indicates that the platform BIOS is not sending the usual TPM_Startup command during S3 resume. >From this point onwards, all TPM commands will fail. The same issue was previously reported on Foxconn 6150BK8MC and Sony Vaio TX3. The platform behaviour seems broken here, but we should not break suspend/resume because of this. When the unexpected TPM state is encountered, set a flag to skip the affected TPM_SaveState command on later suspends. Cc: stable(a)vger.kernel.org Signed-off-by: Chris Chiu <chiu(a)endlessm.com> Signed-off-by: Daniel Drake <drake(a)endlessm.com> Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23Ui… Link: https://lkml.org/lkml/2011/3/28/192 Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031 Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 47aacecdc85c..22288ff70a0b 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -1002,6 +1002,10 @@ int tpm_do_selftest(struct tpm_chip *chip) loops = jiffies_to_msecs(duration) / delay_msec; rc = tpm_continue_selftest(chip); + if (rc == TPM_ERR_INVALID_POSTINIT) { + chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED; + dev_info(&chip->dev, "TPM not ready (%d)\n", rc); + } /* This may fail if there was no TPM driver during a suspend/resume * cycle; some may return 10 (BAD_ORDINAL), others 28 (FAILEDSELFTEST) */

7 years, 6 months

2
1
0 0

[PATCH] random: fix possible sleeping allocation from irq context

by Theodore Ts'o

We can do a sleeping allocation from an irq context when CONFIG_NUMA is enabled. Fix this by initializing the NUMA crng instances in a workqueue. Reported-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reported-by: syzbot+9de458f6a5e713ee8c1a(a)syzkaller.appspotmail.com Fixes: 8ef35c866f8862df ("random: set up the NUMA crng instances...") Cc: stable(a)vger.kernel.org Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> --- drivers/char/random.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 3cd3aae24d6d..e182cca7e6cd 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -789,7 +789,7 @@ static void crng_initialize(struct crng_state *crng) } #ifdef CONFIG_NUMA -static void numa_crng_init(void) +static void do_numa_crng_init(struct work_struct *work) { int i; struct crng_state *crng; @@ -810,6 +810,13 @@ static void numa_crng_init(void) kfree(pool); } } + +DECLARE_WORK(numa_crng_init_work, do_numa_crng_init); + +static void numa_crng_init(void) +{ + schedule_work(&numa_crng_init_work); +} #else static void numa_crng_init(void) {} #endif -- 2.16.1.72.g5be1f00a9a

7 years, 6 months

3
3
0 0

[PATCH V2] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

by Shilpasri G Bhat

gpstate_timer_handler() uses synchronous smp_call to set the pstate on the requested core. This causes the below hard lockup: [c000003fe566b320] [c0000000001d5340] smp_call_function_single+0x110/0x180 (unreliable) [c000003fe566b390] [c0000000001d55e0] smp_call_function_any+0x180/0x250 [c000003fe566b3f0] [c000000000acd3e8] gpstate_timer_handler+0x1e8/0x580 [c000003fe566b4a0] [c0000000001b46b0] call_timer_fn+0x50/0x1c0 [c000003fe566b520] [c0000000001b4958] expire_timers+0x138/0x1f0 [c000003fe566b590] [c0000000001b4bf8] run_timer_softirq+0x1e8/0x270 [c000003fe566b630] [c000000000d0d6c8] __do_softirq+0x158/0x3e4 [c000003fe566b710] [c000000000114be8] irq_exit+0xe8/0x120 [c000003fe566b730] [c000000000024d0c] timer_interrupt+0x9c/0xe0 [c000003fe566b760] [c000000000009014] decrementer_common+0x114/0x120 -- interrupt: 901 at doorbell_global_ipi+0x34/0x50 LR = arch_send_call_function_ipi_mask+0x120/0x130 [c000003fe566ba50] [c00000000004876c] arch_send_call_function_ipi_mask+0x4c/0x130 [c000003fe566ba90] [c0000000001d59f0] smp_call_function_many+0x340/0x450 [c000003fe566bb00] [c000000000075f18] pmdp_invalidate+0x98/0xe0 [c000003fe566bb30] [c0000000003a1120] change_huge_pmd+0xe0/0x270 [c000003fe566bba0] [c000000000349278] change_protection_range+0xb88/0xe40 [c000003fe566bcf0] [c0000000003496c0] mprotect_fixup+0x140/0x340 [c000003fe566bdb0] [c000000000349a74] SyS_mprotect+0x1b4/0x350 [c000003fe566be30] [c00000000000b184] system_call+0x58/0x6c One way to avoid this is removing the smp-call. We can ensure that the timer always runs on one of the policy-cpus. If the timer gets migrated to a cpu outside the policy then re-queue it back on the policy->cpus. This way we can get rid of the smp-call which was being used to set the pstate on the policy->cpus. Fixes: 7bc54b652f13 (timers, cpufreq/powernv: Initialize the gpstate timer as pinned) Cc: <stable(a)vger.kernel.org> [4.8+] Reported-by: Nicholas Piggin <npiggin(a)gmail.com> Reported-by: Pridhiviraj Paidipeddi <ppaidipe(a)linux.vnet.ibm.com> Signed-off-by: Shilpasri G Bhat <shilpa.bhat(a)linux.vnet.ibm.com> --- Changes from V1: - Remove smp_call in the pstate handler. drivers/cpufreq/powernv-cpufreq.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c index 71f8682..dc8ffb5 100644 --- a/drivers/cpufreq/powernv-cpufreq.c +++ b/drivers/cpufreq/powernv-cpufreq.c @@ -679,6 +679,25 @@ void gpstate_timer_handler(struct timer_list *t) if (!spin_trylock(&gpstates->gpstate_lock)) return; + /* + * If the timer has migrated to the different cpu then bring + * it back to one of the policy->cpus + */ + if (!cpumask_test_cpu(raw_smp_processor_id(), policy->cpus)) { + /* + * Timer should be deleted if policy is inactive. + * If policy is active then re-queue on one of the + * policy->cpus. + */ + if (!cpumask_empty(policy->cpus)) { + gpstates->timer.expires = jiffies + + msecs_to_jiffies(1); + add_timer_on(&gpstates->timer, + cpumask_first(policy->cpus)); + } + spin_unlock(&gpstates->gpstate_lock); + return; + } /* * If PMCR was last updated was using fast_swtich then @@ -718,10 +737,8 @@ void gpstate_timer_handler(struct timer_list *t) if (gpstate_idx != gpstates->last_lpstate_idx) queue_gpstate_timer(gpstates); + set_pstate(&freq_data); spin_unlock(&gpstates->gpstate_lock); - - /* Timer may get migrated to a different cpu on cpu hot unplug */ - smp_call_function_any(policy->cpus, set_pstate, &freq_data, 1); } /* -- 1.8.3.1

7 years, 6 months

2
3
0 0

FAILED: patch "[PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE" failed to apply to 4.16-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.16-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bcb0b981c5571744ac446a6c906aa05a28d21446 Mon Sep 17 00:00:00 2001 From: Ben Crocker <bcrocker(a)redhat.com> Date: Thu, 22 Feb 2018 17:52:19 -0500 Subject: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE In radeon_device_init, set the need_dma32 flag for Cedar chips (e.g. FirePro 2270). This fixes, or at least works around, a bug on PowerPC exposed by last year's commits 8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey) and 253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple) which enabled the 64-bit DMA iommu bypass. This caused the device to freeze, in some cases unrecoverably, and is the subject of several bug reports internal to Red Hat. Signed-off-by: Ben Crocker <bcrocker(a)redhat.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 7f40c6f7c4dd..e415d2c097a7 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1366,6 +1366,10 @@ int radeon_device_init(struct radeon_device *rdev, if ((rdev->flags & RADEON_IS_PCI) && (rdev->family <= CHIP_RS740)) rdev->need_dma32 = true; +#ifdef CONFIG_PPC64 + if (rdev->family == CHIP_CEDAR) + rdev->need_dma32 = true; +#endif dma_bits = rdev->need_dma32 ? 32 : 40; r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));

7 years, 6 months

3
3
0 0

Re: [PATCH] ACPI / video: Only default only_lcd to true on Win8-ready _desktops_

by James Hogan

On Tue, Apr 24, 2018 at 11:13:25PM +0200, Hans de Goede wrote: > FWIW this has gotten into 4.15 without it having a Cc: stable or a > Fixes: tag, I think it was picked up by the new magic scripts scripts > which try to find commits which should have a Cc: stable but are lacking > one. > > In this case I deliberately did not add a Cc: stable as what gets fixed > is not that important, whereas the possible regression this might cause > (and actually seems to be causing) is sorta bad. This isn't the first time I've seen patches backported that simply don't need to be, or shouldn't be. In one case a few years back the patch had a fixes tag, but it still wasn't important to backport, which is why I left off the Cc stable, and in fact it broke something. TBH its a bit distracting having to review such patches, which I've already looked at before, determined there's no need for a backport, and subsequently paged out of my head. Stable folk: is there already (and should there be) a defined mechanism to record that a given patch is: 1) not suitable/worthwhile to backport (e.g. even though it might have a Fixes tag or use the word "fix"). 2) OR it would require a bit more human effort to backport (perhaps it applies cleanly but would be expected not to build/work) and probably shouldn't be attempted automatically. 3) OR it probably isn't worth backporting and is risky to do so, and so should only be carefully attempted if somebody actually complains. other than simply stating it in prose in the commit message? Cheers James

7 years, 6 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror