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

Re: [PATCH] pinctrl: freescale: off by one in imx1_pinconf_group_dbg_show()

by Uwe Kleine-König

Hello, On Mon, Jul 30, 2018 at 05:43:43PM +0200, Linus Walleij wrote: > On Fri, Jul 13, 2018 at 4:55 PM Dan Carpenter <dan.carpenter(a)oracle.com> wrote: > > > The info->groups[] array is allocated in imx1_pinctrl_parse_dt(). It > > has info->ngroups elements. Thus the > here should be >= to prevent > > reading one element beyond the end of the array. > > > > Fixes: 30612cd90005 ("pinctrl: imx1 core driver") > > Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> > > Patch applied. > > I am not tagging for stable as it is debug code and does not > affect end users. Not sure this is a valid reason. Distro kernels usually enable debugfs. I'd say an out-of-bounds access that can only be triggered by root should still be fixed. I won't argue but added stable to the addressees of this mail to at least raise awareness. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |

7 years, 1 month

2
1
0 0

[PATCH v2] drm/amd/display: Report non-DP display as disconnected without EDID

by Harry Wentland

[Why] Some boards seem to have a problem where HPD is high on HDMI even though no display is connected. We don't want to report these as connected. DP spec still requires us to report DP displays as connected when HPD is high but we can't read the EDID in order to go to fail-safe mode. [How] If connector_signal is not DP abort detection if we can't retrieve the EDID. Bugzilla: https://bugs.freedesktop.org/107390 Bugzilla: https://bugs.freedesktop.org/106846 Cc: stable(a)vger.kernel.org Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> v2: Add Bugzilla and stable --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index b180197a41e2..84f0fd15be4c 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -744,6 +744,17 @@ bool dc_link_detect(struct dc_link *link, enum dc_detect_reason reason) break; case EDID_NO_RESPONSE: DC_LOG_ERROR("No EDID read.\n"); + + /* + * Abort detection for non-DP connectors if we have + * no EDID + * + * DP needs to report as connected if HDP is high + * even if we have no EDID in order to go to + * fail-safe mode + */ + if (!dc_is_dp_signal(link->connector_signal)) + return false; default: break; } -- 2.17.1

7 years, 1 month

2
1
0 0

request to include on 4.14.y: a4c447533a18ee86e07232d6344ba12b1f9c5077

by Eduardo Valentin

Greg, This is a straight forward cherry-pick. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Thanks. -- All the best, Eduardo Valentin

7 years, 1 month

2
3
0 0

Re: [PATCH] HID: Bluetooth: hidp: buffer overflow in hidp_process_report

by Mark Salyzyn

On 08/01/2018 09:37 AM, Greg KH wrote: > On Tue, Jul 31, 2018 at 03:02:13PM -0700, Mark Salyzyn wrote: >> CVE-2018-9363 >> >> The buffer length is unsigned at all layers, but gets cast to int and >> checked in hidp_process_report and can lead to a buffer overflow. >> Switch len parameter to unsigned int to resolve issue. >> >> This affects 3.18 and newer kernels. >> >> Signed-off-by: Mark Salyzyn <salyzyn(a)android.com> >> Fixes: a4b1b5877b514b276f0f31efe02388a9c2836728 ("HID: Bluetooth: hidp: make sure input buffers are big enough") >> Cc: Marcel Holtmann <marcel(a)holtmann.org> >> Cc: Johan Hedberg <johan.hedberg(a)gmail.com> >> Cc: "David S. Miller" <davem(a)davemloft.net> >> Cc: Kees Cook <keescook(a)chromium.org> >> Cc: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> >> Cc: linux-bluetooth(a)vger.kernel.org >> Cc: netdev(a)vger.kernel.org >> Cc: linux-kernel(a)vger.kernel.org >> Cc: security(a)kernel.org >> Cc: kernel-team(a)android.com > Nit, you only need to bother security@ if you do not have a fix and need > to figure out one. Thanks, I thought anything with a CVE was to go there according to netdev FAQ (dropped security from response list). > Also, you forgot to cc: stable(a)vger.kernel.org to be included in older > kernel releases :( netdev FAQ said to _not_ copy stable, I am so confused ;-{ (added stable to response list b/c patch is now taken into bluetooth-next) > thanks, > > greg k-h

7 years, 1 month

2
1
0 0

Re: [PATCH v2] arch/x86: Fix boot_cpu_data.microcode version output

by Oleksandr Natalenko

Hi. > I tested this on AMD Ryzen & Intel Broadwell system and dumped the > boot_cpu_data before and after a microcode update. On the Intel > system I also did a fatal MCE using mce-inject to confirm the output > from the mce handling code. > > P. > > ---8<--- > > On systems where a runtime microcode update has occurred the microcode > version output in a MCE log record is wrong because > boot_cpu_data.microcode is not updated during runtime. > > Update boot_cpu_data.microcode when the BSP's microcode is updated. > > Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check > records") > Suggested-by: Borislav Petkov <bp(a)alien8.com> > Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> > Cc: stable(a)vger.kernel.org > Cc: sironi(a)amazon.de > Cc: tony.luck(a)intel.com > --- > Changes in v2: Use mc_amd->hdr.patch_id on AMD > > arch/x86/kernel/cpu/microcode/amd.c | 4 ++++ > arch/x86/kernel/cpu/microcode/intel.c | 4 ++++ > 2 files changed, 8 insertions(+) > > diff --git a/arch/x86/kernel/cpu/microcode/amd.c > b/arch/x86/kernel/cpu/microcode/amd.c > index 0624957aa068..63b072377ba4 100644 > --- a/arch/x86/kernel/cpu/microcode/amd.c > +++ b/arch/x86/kernel/cpu/microcode/amd.c > @@ -537,6 +537,10 @@ static enum ucode_state apply_microcode_amd(int > cpu) > uci->cpu_sig.rev = mc_amd->hdr.patch_id; > c->microcode = mc_amd->hdr.patch_id; > > + /* Update boot_cpu_data's revision too, if we're on the BSP: */ > + if (c->cpu_index == boot_cpu_data.cpu_index) > + boot_cpu_data.microcode = mc_amd->hdr.patch_id; > + > return UCODE_UPDATED; > } > > diff --git a/arch/x86/kernel/cpu/microcode/intel.c > b/arch/x86/kernel/cpu/microcode/intel.c > index 97ccf4c3b45b..256d336cbc04 100644 > --- a/arch/x86/kernel/cpu/microcode/intel.c > +++ b/arch/x86/kernel/cpu/microcode/intel.c > @@ -851,6 +851,10 @@ static enum ucode_state apply_microcode_intel(int > cpu) > uci->cpu_sig.rev = rev; > c->microcode = rev; > > + /* Update boot_cpu_data's revision too, if we're on the BSP: */ > + if (c->cpu_index == boot_cpu_data.cpu_index) > + boot_cpu_data.microcode = rev; > + > return UCODE_UPDATED; > } > > -- > 2.17.0 After this patch, do we preserve an original microcode version somewhere? If no, why? Sometimes it is useful while debugging another crash because of faulty microcode. Thanks. -- Oleksandr Natalenko (post-factum)

7 years, 1 month

2
2
0 0

Re: [PATCH v3 02/14] ARM: dts: sunxi: h3/h5: Fix i2c2 register address

by Icenowy Zheng

在 2017-09-26二的 09:22 +0200，Corentin Labbe写道： > The unit address and register address does not match. > This patch fix the register address with the good one. > > Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> > Signed-off-by: Corentin Labbe <clabbe.montjoie(a)gmail.com> This patch should be backported. Older LTS also needs patches, but the patch needs to be refactored to suite the versions. Cc: stable(a)vger.kernel.org # 4.14 > --- > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi > index b37ed3461229..289f2cd06dfe 100644 > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi > @@ -632,7 +632,7 @@ > > i2c2: i2c@1c2b400 { > compatible = "allwinner,sun6i-a31-i2c"; > - reg = <0x01c2b000 0x400>; > + reg = <0x01c2b400 0x400>; > interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; > clocks = <&ccu CLK_BUS_I2C2>; > resets = <&ccu RST_BUS_I2C2>;

7 years, 1 month

1
0
0 0

2018-7_租務精選

by Flourish_萊斯物業

7 years, 1 month

1
0
0 0

[PATCHES] Networking

by David Miller

Please queue up the following networking bug fixes for 4.14.x and 4.17.x -stable, respectively. Thanks!

7 years, 1 month

2
1
0 0

[PATCH v3 3/3] RDMA/mlx5: Fix shift overflow in mlx5_ib_create_wq

by Kees Cook

From: Leon Romanovsky <leonro(a)mellanox.com> [ 61.182439] UBSAN: Undefined behaviour in drivers/infiniband/hw/mlx5/qp.c:5366:34 [ 61.183673] shift exponent 4294967288 is too large for 32-bit type 'unsigned int' [ 61.185530] CPU: 0 PID: 639 Comm: qp Not tainted 4.18.0-rc1-00037-g4aa1d69a9c60-dirty #96 [ 61.186981] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 [ 61.188315] Call Trace: [ 61.188661] dump_stack+0xc7/0x13b [ 61.190427] ubsan_epilogue+0x9/0x49 [ 61.190899] __ubsan_handle_shift_out_of_bounds+0x1ea/0x22f [ 61.197040] mlx5_ib_create_wq+0x1c99/0x1d50 [ 61.206632] ib_uverbs_ex_create_wq+0x499/0x820 [ 61.213892] ib_uverbs_write+0x77e/0xae0 [ 61.248018] vfs_write+0x121/0x3b0 [ 61.249831] ksys_write+0xa1/0x120 [ 61.254024] do_syscall_64+0x7c/0x2a0 [ 61.256178] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 61.259211] RIP: 0033:0x7f54bab70e99 [ 61.262125] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 [ 61.268678] RSP: 002b:00007ffe1541c318 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 61.271076] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f54bab70e99 [ 61.273795] RDX: 0000000000000070 RSI: 0000000020000240 RDI: 0000000000000003 [ 61.276982] RBP: 00007ffe1541c330 R08: 00000000200078e0 R09: 0000000000000002 [ 61.280035] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004005c0 [ 61.283279] R13: 00007ffe1541c420 R14: 0000000000000000 R15: 0000000000000000 Cc: <stable(a)vger.kernel.org> # 4.7 Fixes: 79b20a6c3014 ("IB/mlx5: Add receive Work Queue verbs") Cc: syzkaller <syzkaller(a)googlegroups.com> Reported-by: Noa Osherovich <noaos(a)mellanox.com> Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> --- drivers/infiniband/hw/mlx5/qp.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c index a4f1f638509f..7fc156db643d 100644 --- a/drivers/infiniband/hw/mlx5/qp.c +++ b/drivers/infiniband/hw/mlx5/qp.c @@ -5365,7 +5365,10 @@ static int set_user_rq_size(struct mlx5_ib_dev *dev, rwq->wqe_count = ucmd->rq_wqe_count; rwq->wqe_shift = ucmd->rq_wqe_shift; - rwq->buf_size = (rwq->wqe_count << rwq->wqe_shift); + if (check_shift_overflow(rwq->wqe_count, rwq->wqe_shift, + &rwq->buf_size)) + return -EINVAL; + rwq->log_rq_stride = rwq->wqe_shift; rwq->log_rq_size = ilog2(rwq->wqe_count); return 0; -- 2.17.1

7 years, 1 month

1
0
0 0

[PATCH] drm/i915/gvt: move intel_runtime_pm_get out of spin_lock in stop_schedule

by hang.yuan＠linux.intel.com

From: Hang Yuan <hang.yuan(a)linux.intel.com> pm_runtime_get_sync in intel_runtime_pm_get might sleep if i915 device is not active. When stop vgpu schedule, the device may be inactive. So need to move runtime_pm_get out of spin_lock/unlock. Fixes: b24881e0b0b6("drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio Signed-off-by: Hang Yuan <hang.yuan(a)linux.intel.com> Signed-off-by: Xiong Zhang <xiong.y.zhang(a)intel.com> --- drivers/gpu/drm/i915/gvt/mmio_context.c | 2 -- drivers/gpu/drm/i915/gvt/sched_policy.c | 3 +++ 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c b/drivers/gpu/drm/i915/gvt/mmio_context.c index 7e702c6..10e63ee 100644 --- a/drivers/gpu/drm/i915/gvt/mmio_context.c +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c @@ -549,11 +549,9 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre, * performace for batch mmio read/write, so we need * handle forcewake mannually. */ - intel_runtime_pm_get(dev_priv); intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL); switch_mmio(pre, next, ring_id); intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); - intel_runtime_pm_put(dev_priv); } /** diff --git a/drivers/gpu/drm/i915/gvt/sched_policy.c b/drivers/gpu/drm/i915/gvt/sched_policy.c index 09d7bb7..985fe81 100644 --- a/drivers/gpu/drm/i915/gvt/sched_policy.c +++ b/drivers/gpu/drm/i915/gvt/sched_policy.c @@ -426,6 +426,7 @@ void intel_vgpu_stop_schedule(struct intel_vgpu *vgpu) &vgpu->gvt->scheduler; int ring_id; struct vgpu_sched_data *vgpu_data = vgpu->sched_data; + struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv; if (!vgpu_data->active) return; @@ -444,6 +445,7 @@ void intel_vgpu_stop_schedule(struct intel_vgpu *vgpu) scheduler->current_vgpu = NULL; } + intel_runtime_pm_get(dev_priv); spin_lock_bh(&scheduler->mmio_context_lock); for (ring_id = 0; ring_id < I915_NUM_ENGINES; ring_id++) { if (scheduler->engine_owner[ring_id] == vgpu) { @@ -452,5 +454,6 @@ void intel_vgpu_stop_schedule(struct intel_vgpu *vgpu) } } spin_unlock_bh(&scheduler->mmio_context_lock); + intel_runtime_pm_put(dev_priv); mutex_unlock(&vgpu->gvt->sched_lock); } -- 2.7.4

7 years, 1 month

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror