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

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, 4 months

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, 4 months

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, 4 months

1
0
0 0

2018-7_租務精選

by Flourish_萊斯物業

7 years, 4 months

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, 4 months

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, 4 months

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, 4 months

3
2
0 0

[PATCH v2 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, 4 months

1
0
0 0

+ userfaultfd-remove-uffd-flags-from-vma-vm_flags-if-uffd_event_fork-fails.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: userfaultfd: remove uffd flags from vma->vm_flags if UFFD_EVENT_FORK fails has been added to the -mm tree. Its filename is userfaultfd-remove-uffd-flags-from-vma-vm_flags-if-uffd_event_fork-fails.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/userfaultfd-remove-uffd-flags-from… and later at http://ozlabs.org/~akpm/mmotm/broken-out/userfaultfd-remove-uffd-flags-from… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Subject: userfaultfd: remove uffd flags from vma->vm_flags if UFFD_EVENT_FORK fails The fix in 0cbb4b4f4c44 ("userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails") cleared the vma->vm_userfaultfd_ctx but kept userfaultfd flags in vma->vm_flags that were copied from the parent process VMA. As the result, there is an inconsistency between the values of vma->vm_userfaultfd_ctx.ctx and vma->vm_flags which triggers BUG_ON in userfaultfd_release(). Clearing the uffd flags from vma->vm_flags in case of UFFD_EVENT_FORK failure resolves the issue. Link: http://lkml.kernel.org/r/1532931975-25473-1-git-send-email-rppt@linux.vnet.… Fixes: 0cbb4b4f4c44 ("userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails") Signed-off-by: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Reported-by: syzbot+121be635a7a35ddb7dcb(a)syzkaller.appspotmail.com Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Eric Biggers <ebiggers3(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN fs/userfaultfd.c~userfaultfd-remove-uffd-flags-from-vma-vm_flags-if-uffd_event_fork-fails fs/userfaultfd.c --- a/fs/userfaultfd.c~userfaultfd-remove-uffd-flags-from-vma-vm_flags-if-uffd_event_fork-fails +++ a/fs/userfaultfd.c @@ -633,8 +633,10 @@ static void userfaultfd_event_wait_compl /* the various vma->vm_userfaultfd_ctx still points to it */ down_write(&mm->mmap_sem); for (vma = mm->mmap; vma; vma = vma->vm_next) - if (vma->vm_userfaultfd_ctx.ctx == release_new_ctx) + if (vma->vm_userfaultfd_ctx.ctx == release_new_ctx) { vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX; + vma->vm_flags &= ~(VM_UFFD_WP | VM_UFFD_MISSING); + } up_write(&mm->mmap_sem); userfaultfd_ctx_put(release_new_ctx); _ Patches currently in -mm which might be from rppt(a)linux.vnet.ibm.com are userfaultfd-remove-uffd-flags-from-vma-vm_flags-if-uffd_event_fork-fails.patch mm-make-deferred_struct_page_init-explicitly-depend-on-sparsemem.patch mm-memblock-replace-u64-with-phys_addr_t-where-appropriate.patch mm-mempool-add-missing-parameter-description.patch mm-util-make-strndup_user-description-a-kernel-doc-comment.patch mm-util-add-kernel-doc-for-kvfree.patch docs-core-api-kill-trailing-whitespace-in-kernel-apirst.patch docs-core-api-move-strmemdup-to-string-manipulation.patch docs-core-api-split-memory-management-api-to-a-separate-file.patch docs-mm-make-gfp-flags-descriptions-usable-as-kernel-doc.patch docs-core-api-mm-api-add-section-about-gfp-flags.patch

7 years, 4 months

1
0
0 0

Are you sure?

by Ms CHIANG Lai Yuen JP

I have a Businesss Proposal for you, Can you do it? If yes please get back to me for more details.

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror