August 2021 - Linux-stable-mirror

Drivers for Qualcomm wifi chips (ath*k) and security issues

by Pali Rohár

Hello Sasha and Greg! Last week I sent request for backporting ath9k wifi fixes for security issue CVE-2020-3702 into stable LTS kernels because Qualcomm/maintainers did not it for more months... details are in email: https://lore.kernel.org/stable/20210818084859.vcs4vs3yd6zetmyt@pali/t/#u And now I got reports that in stable LTS kernels (4.14, 4.19) are missing also other fixes for other Qualcomm wifi security issues, covered by FragAttacks codename: CVE-2020-26145 CVE-2020-26139 CVE-2020-26141 People have already asked if somebody is already doing backports to 4.19 of patches for these security issues, but there was no response, see email: https://lore.kernel.org/linux-wireless/704e1c77-6c48-79f7-043a-b2d03fbfef8b… I got information that issues for ath10k are again going to be (or are already?) fixed in some vendor custom/fork kernels, but not in official stable tree 4.14/4.19 (yet). This situation is really bad because lot of times I hear to use mainline kernel versions or official stable LTS tree (which are maintained by you), but due to such security issues in LTS trees which stays unfixed and others say to use rather vendor custom/fork kernels where it is claimed that issues are fixed. And because there is no statement for end users (end users do not communicate with vendors and so they do not have information what is supported and what not), end users just use what Linux open source distributions have in their kernels (which lot of times match official LTS kernel trees). And users think that everything is OK and security issues are fixed. So there is really a need for public statement from you or Qualcomm side, if stable LTS kernel trees are going to include security fixes for drivers used by Qualcomm wifi chips (ath*k) or not or under which conditions. And what should users / Linux distributions use if they do not want to have years-old unpatched drivers with security issues. Such information is really important also for distributions which include unmodified (or slightly modified) kernel LTS trees into their own packages. As they also need to know from which source should take (e.g. Qualcomm wifi) drivers for their systems to ensure that have security patches applied. I can understand that you or other people or volunteers do not have time to track or maintain some parts of drivers. So nothing wrong if official statement is that stable trees X and Y do not receive security updates for driver A and B anymore. Also I can understand that it takes some time to include required fixes, so expect fixes for A and B in X and Y versions with one month delay. But it is needed to know what should people expect from LTS trees for particular drivers. Because I think it is not currently clear... Do not take me wrong, I just wanted to show that this is hidden problem which needs some discussion.

3 years, 2 months

6
7
0 0

[PATCH] bus: mhi: pci_generic: increase timeout value for operations to 24000ms

by Thomas Perrot

Otherwise, the waiting time was too short to use a Sierra Wireless EM919X connected to an i.MX6 through the PCIe bus. Signed-off-by: Thomas Perrot <thomas.perrot(a)bootlin.com> --- drivers/bus/mhi/pci_generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bus/mhi/pci_generic.c b/drivers/bus/mhi/pci_generic.c index 4dd1077354af..e08ed6e5031b 100644 --- a/drivers/bus/mhi/pci_generic.c +++ b/drivers/bus/mhi/pci_generic.c @@ -248,7 +248,7 @@ static struct mhi_event_config modem_qcom_v1_mhi_events[] = { static const struct mhi_controller_config modem_qcom_v1_mhiv_config = { .max_channels = 128, - .timeout_ms = 8000, + .timeout_ms = 24000, .num_channels = ARRAY_SIZE(modem_qcom_v1_mhi_channels), .ch_cfg = modem_qcom_v1_mhi_channels, .num_events = ARRAY_SIZE(modem_qcom_v1_mhi_events), -- 2.31.1

3 years, 2 months

4
12
0 0

[PATCH 08/19] drm/i915: Fix runtime pm handling in i915_gem_shrink

by Maarten Lankhorst

We forgot to call intel_runtime_pm_put on error, fix it! Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.") Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: <stable(a)vger.kernel.org> # v5.13+ --- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c index e382b7f2353b..5ab136ffdeb2 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c @@ -118,7 +118,7 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww, intel_wakeref_t wakeref = 0; unsigned long count = 0; unsigned long scanned = 0; - int err; + int err = 0; /* CHV + VTD workaround use stop_machine(); need to trylock vm->mutex */ bool trylock_vm = !ww && intel_vm_no_concurrent_access_wa(i915); @@ -242,12 +242,15 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww, list_splice_tail(&still_in_list, phase->list); spin_unlock_irqrestore(&i915->mm.obj_lock, flags); if (err) - return err; + break; } if (shrink & I915_SHRINK_BOUND) intel_runtime_pm_put(&i915->runtime_pm, wakeref); + if (err) + return err; + if (nr_scanned) *nr_scanned += scanned; return count; -- 2.32.0

3 years, 2 months

3
4
0 0

Request for backport fd6bc19d7676 to 4.14 and 4.19 branch

by David Chen

Hi Greg, We recently hit a hung task timeout issue in synchronize_rcu_expedited on 4.14 branch. The issue seems to be identical to the one described in `fd6bc19d7676 rcu: Fix missed wakeup of exp_wq waiters` Can we backport it to 4.14 and 4.19 branch? The patch doesn't apply cleanly, but it should be trivial to resolve, just do this - wake_up_all(&rnp->exp_wq[rcu_seq_ctr(rsp->expedited_sequence) & 0x3]); + wake_up_all(&rnp->exp_wq[rcu_seq_ctr(s) & 0x3]); I don't know if we should do it for 4.9, because the handling of sequence number is a bit different. Thanks, David

3 years, 3 months

3
8
0 0

[PATCH 2/4] xhci: Improve detection of device initiated wake signal.

by Mathias Nyman

A xHC USB 3 port might miss the first wake signal from a USB 3 device if the port LFPS reveiver isn't enabled fast enough after xHC resume. xHC host will anyway be resumed by a PME# signal, but will go back to suspend if no port activity is seen. The device resends the U3 LFPS wake signal after a 100ms delay, but by then host is already suspended, starting all over from the beginning of this issue. USB 3 specs say U3 wake LFPS signal is sent for max 10ms, then device needs to delay 100ms before resending the wake. Don't suspend immediately if port activity isn't detected in resume. Instead add a retry. If there is no port activity then delay for 120ms, and re-check for port activity. Cc: <stable(a)vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index bd27bd670104..48a68fcf2b36 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -1088,6 +1088,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated) struct usb_hcd *secondary_hcd; int retval = 0; bool comp_timer_running = false; + bool pending_portevent = false; if (!hcd->state) return 0; @@ -1226,13 +1227,22 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated) done: if (retval == 0) { - /* Resume root hubs only when have pending events. */ - if (xhci_pending_portevent(xhci)) { + /* + * Resume roothubs only if there are pending events. + * USB 3 devices resend U3 LFPS wake after a 100ms delay if + * the first wake signalling failed, give it that chance. + */ + pending_portevent = xhci_pending_portevent(xhci); + if (!pending_portevent) { + msleep(120); + pending_portevent = xhci_pending_portevent(xhci); + } + + if (pending_portevent) { usb_hcd_resume_root_hub(xhci->shared_hcd); usb_hcd_resume_root_hub(hcd); } } - /* * If system is subject to the Quirk, Compliance Mode Timer needs to * be re-initialized Always after a system resume. Ports are subject -- 2.25.1

3 years, 3 months

3
2
0 0

[PATCH 1/2] ARM: dts: imx6dl-yapp4: Fix lp5562 LED driver probe

by Michal Vokáč

Since the LED multicolor framework support was added in commit 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") LEDs on this platform stopped working. Author of the framework attempted to accommodate this DT to the framework in commit b86d3d21cd4c ("ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node") but that is not sufficient. A color property is now required even if the multicolor framework is not used, otherwise the driver probe fails: lp5562: probe of 1-0030 failed with error -22 Add the color property to fix this. Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") Cc: <stable(a)vger.kernel.org> Cc: linux-leds(a)vger.kernel.org Signed-off-by: Michal Vokáč <michal.vokac(a)ysoft.com> --- arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi index 7d2c72562c73..8c796551352b 100644 --- a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi +++ b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi @@ -5,6 +5,7 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/input/input.h> +#include <dt-bindings/leds/common.h> #include <dt-bindings/pwm/pwm.h> / { @@ -271,6 +272,7 @@ chan@0 { led-cur = /bits/ 8 <0x20>; max-cur = /bits/ 8 <0x60>; reg = <0>; + color = <LED_COLOR_ID_RED>; }; chan@1 { @@ -278,6 +280,7 @@ chan@1 { led-cur = /bits/ 8 <0x20>; max-cur = /bits/ 8 <0x60>; reg = <1>; + color = <LED_COLOR_ID_GREEN>; }; chan@2 { @@ -285,6 +288,7 @@ chan@2 { led-cur = /bits/ 8 <0x20>; max-cur = /bits/ 8 <0x60>; reg = <2>; + color = <LED_COLOR_ID_BLUE>; }; chan@3 { @@ -292,6 +296,7 @@ chan@3 { led-cur = /bits/ 8 <0x0>; max-cur = /bits/ 8 <0x0>; reg = <3>; + color = <LED_COLOR_ID_WHITE>; }; }; -- 2.25.1

3 years, 3 months

4
4
0 0

[PATCH V2] video: backlight: Drop maximum brightness override for brightness zero

by Marek Vasut

The note in c2adda27d202f ("video: backlight: Add of_find_backlight helper in backlight.c") says that gpio-backlight uses brightness as power state. This has been fixed since in ec665b756e6f7 ("backlight: gpio-backlight: Correct initial power state handling") and other backlight drivers do not require this workaround. Drop the workaround. This fixes the case where e.g. pwm-backlight can perfectly well be set to brightness 0 on boot in DT, which without this patch leads to the display brightness to be max instead of off. Fixes: c2adda27d202f ("video: backlight: Add of_find_backlight helper in backlight.c") Acked-by: Noralf Trønnes <noralf(a)tronnes.org> Reviewed-by: Daniel Thompson <daniel.thompson(a)linaro.org> Cc: <stable(a)vger.kernel.org> # 5.4+ Cc: <stable(a)vger.kernel.org> # 4.19.x: ec665b756e6f7: backlight: gpio-backlight: Correct initial power state handling Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Daniel Thompson <daniel.thompson(a)linaro.org> Cc: Meghana Madhyastha <meghana.madhyastha(a)gmail.com> Cc: Noralf Trønnes <noralf(a)tronnes.org> Cc: Sean Paul <seanpaul(a)chromium.org> Cc: Thierry Reding <treding(a)nvidia.com> --- V2: Add AB/RB, CC stable --- drivers/video/backlight/backlight.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index 537fe1b376ad7..fc990e576340b 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -688,12 +688,6 @@ static struct backlight_device *of_find_backlight(struct device *dev) of_node_put(np); if (!bd) return ERR_PTR(-EPROBE_DEFER); - /* - * Note: gpio_backlight uses brightness as - * power state during probe - */ - if (!bd->props.brightness) - bd->props.brightness = bd->props.max_brightness; } } -- 2.30.2

3 years, 3 months

2
3
0 0

[PATCH v2 07/17] irqchip/gic: Atomically update affinity

by Marc Zyngier

The GIC driver uses a RMW sequence to update the affinity, and relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences to update it atomically. But these sequences only expend into anything meaningful if the BL_SWITCHER option is selected, which almost never happens. It also turns out that using a RMW and locks is just as silly, as the GIC distributor supports byte accesses for the GICD_TARGETRn registers, which when used make the update atomic by definition. Drop the terminally broken code and replace it by a byte write. Fixes: 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature") Cc: stable(a)vger.kernel.org Signed-off-by: Marc Zyngier <maz(a)kernel.org> --- drivers/irqchip/irq-gic.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 00de05abd3c3..c17fabd6741e 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -329,10 +329,8 @@ static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu) static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, bool force) { - void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3); - unsigned int cpu, shift = (gic_irq(d) % 4) * 8; - u32 val, mask, bit; - unsigned long flags; + void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + gic_irq(d); + unsigned int cpu; if (!force) cpu = cpumask_any_and(mask_val, cpu_online_mask); @@ -342,13 +340,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids) return -EINVAL; - gic_lock_irqsave(flags); - mask = 0xff << shift; - bit = gic_cpu_map[cpu] << shift; - val = readl_relaxed(reg) & ~mask; - writel_relaxed(val | bit, reg); - gic_unlock_irqrestore(flags); - + writeb_relaxed(gic_cpu_map[cpu], reg); irq_data_update_effective_affinity(d, cpumask_of(cpu)); return IRQ_SET_MASK_OK_DONE; -- 2.27.0

3 years, 3 months

5
11
0 0

Backporting CVE-2020-3702 ath9k patches to stable

by Pali Rohár

Hello! I would like to request for backporting following ath9k commits which are fixing CVE-2020-3702 issue. 56c5485c9e44 ("ath: Use safer key clearing with key cache entries") 73488cb2fa3b ("ath9k: Clear key cache explicitly on disabling hardware") d2d3e36498dd ("ath: Export ath_hw_keysetmac()") 144cd24dbc36 ("ath: Modify ath_key_delete() to not need full key entry") ca2848022c12 ("ath9k: Postpone key cache entry deletion for TXQ frames reference it") See also: https://lore.kernel.org/linux-wireless/87o8hvlx5g.fsf@codeaurora.org/ This CVE-2020-3702 issue affects ath9k driver in stable kernel versions. And due to this issue Qualcomm suggests to not use open source ath9k driver and instead to use their proprietary driver which do not have this issue. Details about CVE-2020-3702 are described on the ESET blog post: https://www.welivesecurity.com/2020/08/06/beyond-kr00k-even-more-wifi-chips… Two months ago ESET tested above mentioned commits applied on top of 4.14 stable tree and confirmed that issue cannot be reproduced anymore with those patches. Commits were applied cleanly on top of 4.14 stable tree without need to do any modification.

3 years, 3 months

5
14
0 0

[PATCH 1/4] cputime, cpuacct: Include guest time in user time in cpuacct.stat

by Andrey Ryabinin

cpuacct.stat in no-root cgroups shows user time without guest time included int it. This doesn't match with user time shown in root cpuacct.stat and /proc/<pid>/stat. Make account_guest_time() to add user time to cgroup's cpustat to fix this. Fixes: ef12fefabf94 ("cpuacct: add per-cgroup utime/stime statistics") Signed-off-by: Andrey Ryabinin <arbn(a)yandex-team.com> Cc: <stable(a)vger.kernel.org> --- kernel/sched/cputime.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c index 5f611658eeab..95a9c5603d29 100644 --- a/kernel/sched/cputime.c +++ b/kernel/sched/cputime.c @@ -139,8 +139,6 @@ void account_user_time(struct task_struct *p, u64 cputime) */ void account_guest_time(struct task_struct *p, u64 cputime) { - u64 *cpustat = kcpustat_this_cpu->cpustat; - /* Add guest time to process. */ p->utime += cputime; account_group_user_time(p, cputime); @@ -148,11 +146,11 @@ void account_guest_time(struct task_struct *p, u64 cputime) /* Add guest time to cpustat. */ if (task_nice(p) > 0) { - cpustat[CPUTIME_NICE] += cputime; - cpustat[CPUTIME_GUEST_NICE] += cputime; + task_group_account_field(p, CPUTIME_NICE, cputime); + task_group_account_field(p, CPUTIME_GUEST_NICE, cputime); } else { - cpustat[CPUTIME_USER] += cputime; - cpustat[CPUTIME_GUEST] += cputime; + task_group_account_field(p, CPUTIME_USER, cputime); + task_group_account_field(p, CPUTIME_GUEST, cputime); } } -- 2.26.2

3 years, 3 months

3
12
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2021