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

[Linux-stable-mirror] [PATCH] KVM: Fix stack-out-of-bounds read in write_mmio

by sawlani＠google.com

From: Pradeep Sawlani <sawlani(a)google.com> commit e39d200fa5bf5b94a0948db0dae44c1b73b84a56 upstream. Reported by syzkaller: BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm] Read of size 8 at addr ffff8803259df7f8 by task syz-executor/32298 CPU: 6 PID: 32298 Comm: syz-executor Tainted: G OE 4.15.0-rc2+ #18 Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS 02/16/2016 Call Trace: dump_stack+0xab/0xe1 print_address_description+0x6b/0x290 kasan_report+0x28a/0x370 write_mmio+0x11e/0x270 [kvm] emulator_read_write_onepage+0x311/0x600 [kvm] emulator_read_write+0xef/0x240 [kvm] emulator_fix_hypercall+0x105/0x150 [kvm] em_hypercall+0x2b/0x80 [kvm] x86_emulate_insn+0x2b1/0x1640 [kvm] x86_emulate_instruction+0x39a/0xb90 [kvm] handle_exception+0x1b4/0x4d0 [kvm_intel] vcpu_enter_guest+0x15a0/0x2640 [kvm] kvm_arch_vcpu_ioctl_run+0x549/0x7d0 [kvm] kvm_vcpu_ioctl+0x479/0x880 [kvm] do_vfs_ioctl+0x142/0x9a0 SyS_ioctl+0x74/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The path of patched vmmcall will patch 3 bytes opcode 0F 01 C1(vmcall) to the guest memory, however, write_mmio tracepoint always prints 8 bytes through *(u64 *)val since kvm splits the mmio access into 8 bytes. This leaks 5 bytes from the kernel stack (CVE-2017-17741). This patch fixes it by just accessing the bytes which we operate on. Before patch: syz-executor-5567 [007] .... 51370.561696: kvm_mmio: mmio write len 3 gpa 0x10 val 0x1ffff10077c1010f After patch: syz-executor-13416 [002] .... 51302.299573: kvm_mmio: mmio write len 3 gpa 0x10 val 0xc1010f Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Reviewed-by: Darren Kenny <darren.kenny(a)oracle.com> Reviewed-by: Marc Zyngier <marc.zyngier(a)arm.com> Tested-by: Marc Zyngier <marc.zyngier(a)arm.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Marc Zyngier <marc.zyngier(a)arm.com> Cc: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Pradeep Sawlani <sawlani(a)google.com> --- arch/arm/kvm/mmio.c | 6 +++--- arch/x86/kvm/x86.c | 8 ++++---- include/trace/events/kvm.h | 7 +++++-- 3 files changed, 12 insertions(+), 9 deletions(-) diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c index 3a10c9f1d0a4..387ee2a11e36 100644 --- a/arch/arm/kvm/mmio.c +++ b/arch/arm/kvm/mmio.c @@ -113,7 +113,7 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu, struct kvm_run *run) } trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr, - data); + &data); data = vcpu_data_host_to_guest(vcpu, data, len); vcpu_set_reg(vcpu, vcpu->arch.mmio_decode.rt, data); } @@ -189,14 +189,14 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run, data = vcpu_data_guest_to_host(vcpu, vcpu_get_reg(vcpu, rt), len); - trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, len, fault_ipa, data); + trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, len, fault_ipa, &data); mmio_write_buf(data_buf, len, data); ret = kvm_io_bus_write(vcpu, KVM_MMIO_BUS, fault_ipa, len, data_buf); } else { trace_kvm_mmio(KVM_TRACE_MMIO_READ_UNSATISFIED, len, - fault_ipa, 0); + fault_ipa, NULL); ret = kvm_io_bus_read(vcpu, KVM_MMIO_BUS, fault_ipa, len, data_buf); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index ccf17dbfea09..f973cfa8ff4f 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4114,7 +4114,7 @@ static int vcpu_mmio_read(struct kvm_vcpu *vcpu, gpa_t addr, int len, void *v) addr, n, v)) && kvm_io_bus_read(vcpu, KVM_MMIO_BUS, addr, n, v)) break; - trace_kvm_mmio(KVM_TRACE_MMIO_READ, n, addr, *(u64 *)v); + trace_kvm_mmio(KVM_TRACE_MMIO_READ, n, addr, v); handled += n; addr += n; len -= n; @@ -4362,7 +4362,7 @@ static int read_prepare(struct kvm_vcpu *vcpu, void *val, int bytes) { if (vcpu->mmio_read_completed) { trace_kvm_mmio(KVM_TRACE_MMIO_READ, bytes, - vcpu->mmio_fragments[0].gpa, *(u64 *)val); + vcpu->mmio_fragments[0].gpa, val); vcpu->mmio_read_completed = 0; return 1; } @@ -4384,14 +4384,14 @@ static int write_emulate(struct kvm_vcpu *vcpu, gpa_t gpa, static int write_mmio(struct kvm_vcpu *vcpu, gpa_t gpa, int bytes, void *val) { - trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, *(u64 *)val); + trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, val); return vcpu_mmio_write(vcpu, gpa, bytes, val); } static int read_exit_mmio(struct kvm_vcpu *vcpu, gpa_t gpa, void *val, int bytes) { - trace_kvm_mmio(KVM_TRACE_MMIO_READ_UNSATISFIED, bytes, gpa, 0); + trace_kvm_mmio(KVM_TRACE_MMIO_READ_UNSATISFIED, bytes, gpa, NULL); return X86EMUL_IO_NEEDED; } diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h index d6f83222a6a1..67ff6555967f 100644 --- a/include/trace/events/kvm.h +++ b/include/trace/events/kvm.h @@ -204,7 +204,7 @@ TRACE_EVENT(kvm_ack_irq, { KVM_TRACE_MMIO_WRITE, "write" } TRACE_EVENT(kvm_mmio, - TP_PROTO(int type, int len, u64 gpa, u64 val), + TP_PROTO(int type, int len, u64 gpa, void *val), TP_ARGS(type, len, gpa, val), TP_STRUCT__entry( @@ -218,7 +218,10 @@ TRACE_EVENT(kvm_mmio, __entry->type = type; __entry->len = len; __entry->gpa = gpa; - __entry->val = val; + __entry->val = 0; + if (val) + memcpy(&__entry->val, val, + min_t(u32, sizeof(__entry->val), len)); ), TP_printk("mmio %s len %u gpa 0x%llx val 0x%llx", -- 2.16.0.rc0.223.g4a4ac83678-goog

7 years, 4 months

3
3
0 0

[Linux-stable-mirror] Patch "x86/vsdo: Fix build on PARAVIRT_CLOCK=y, KVM_GUEST=n" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/vsdo: Fix build on PARAVIRT_CLOCK=y, KVM_GUEST=n to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-vsdo-fix-build-on-paravirt_clock-y-kvm_guest-n.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8705d603edd49f1cff165cd3b7998f4c7f098d27 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 29 Dec 2015 20:12:18 -0800 Subject: x86/vsdo: Fix build on PARAVIRT_CLOCK=y, KVM_GUEST=n From: Andy Lutomirski <luto(a)kernel.org> commit 8705d603edd49f1cff165cd3b7998f4c7f098d27 upstream. arch/x86/built-in.o: In function `arch_setup_additional_pages': (.text+0x587): undefined reference to `pvclock_pvti_cpu0_va' KVM_GUEST selects PARAVIRT_CLOCK, so we can make pvclock_pvti_cpu0_va depend on KVM_GUEST. Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Tested-by: Borislav Petkov <bp(a)alien8.de> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Kees Cook <keescook(a)chromium.org> Link: http://lkml.kernel.org/r/444d38a9bcba832685740ea1401b569861d09a72.145144656… Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: James Dingwall <james(a)dingwall.me.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/pvclock.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/include/asm/pvclock.h +++ b/arch/x86/include/asm/pvclock.h @@ -4,7 +4,7 @@ #include <linux/clocksource.h> #include <asm/pvclock-abi.h> -#ifdef CONFIG_PARAVIRT_CLOCK +#ifdef CONFIG_KVM_GUEST extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void); #else static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void) Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.4/x86-vsdo-fix-build-on-paravirt_clock-y-kvm_guest-n.patch

7 years, 4 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

by Roger Quadros

On 10/01/18 16:04, Felipe Balbi wrote: > > Hi, > > Roger Quadros <rogerq(a)ti.com> writes: >>> Roger Quadros <rogerq(a)ti.com> writes: >>>> Felipe, >>>> >>>> On 10/01/18 15:11, Roger Quadros wrote: >>>>> The USB PHYs should be requested only once during the life cycle of >>>>> this driver. >>>>> >>>>> As dwc3_core_init() is called during system suspend/resume >>>>> it will result in multiple calls to dwc3_core_get_phy() which is wrong. >>>>> >>>>> To prevent that let's move dwc3_core_get_phy() call >>>>> outside dwc3_core_init(). >>>>> >>>>> Fixes: 541768b08a4 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys") >>>>> Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13 >>>>> Signed-off-by: Roger Quadros <rogerq(a)ti.com> >>>> >>>> FYI. this patch brings the code back to >>>> revert 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys") >>>> revert f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get the PHY") >>>> >>>> So looks like this will break ULPI PHY case? >>>> >>>> Where do we initialize ULPI PHY, in dwc3_phy_setup()? >>>> >>>> if so then 541768b08a40 breaks the ULPI PHY case as well, right? >>> >>> indeed, that commit regressed ULPI PHYs :-( >>> >>> Seems like it should be more like below: >>> >>> @@ -754,15 +754,15 @@ static int dwc3_core_init(struct dwc3 *dwc) >>> dwc->maximum_speed = USB_SPEED_HIGH; >>> } >>> >>> - ret = dwc3_core_get_phy(dwc); >>> + ret = dwc3_phy_setup(dwc); >> >> But can we do a dwc3_phy_setup() without doing the soft reset of the controller first? > > as long as clocks are running, we can do that, yes. > >>> - ret = dwc3_core_soft_reset(dwc); >>> + ret = dwc3_core_get_phy(dwc); >> >> we can get_phy in dwc3_core_init() as it will get called on resume(). >> This was the $subject of this patch. > > indeed. thanks :-) > oops sorry. I meant we can't call dwc3_core_get_phy() in dwc3_core_init(). :P -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

7 years, 4 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

by Roger Quadros

On 10/01/18 15:33, Felipe Balbi wrote: > > Hi, > > Roger Quadros <rogerq(a)ti.com> writes: >> Felipe, >> >> On 10/01/18 15:11, Roger Quadros wrote: >>> The USB PHYs should be requested only once during the life cycle of >>> this driver. >>> >>> As dwc3_core_init() is called during system suspend/resume >>> it will result in multiple calls to dwc3_core_get_phy() which is wrong. >>> >>> To prevent that let's move dwc3_core_get_phy() call >>> outside dwc3_core_init(). >>> >>> Fixes: 541768b08a4 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys") >>> Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13 >>> Signed-off-by: Roger Quadros <rogerq(a)ti.com> >> >> FYI. this patch brings the code back to >> revert 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys") >> revert f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get the PHY") >> >> So looks like this will break ULPI PHY case? >> >> Where do we initialize ULPI PHY, in dwc3_phy_setup()? >> >> if so then 541768b08a40 breaks the ULPI PHY case as well, right? > > indeed, that commit regressed ULPI PHYs :-( > > Seems like it should be more like below: > > @@ -754,15 +754,15 @@ static int dwc3_core_init(struct dwc3 *dwc) > dwc->maximum_speed = USB_SPEED_HIGH; > } > > - ret = dwc3_core_get_phy(dwc); > + ret = dwc3_phy_setup(dwc); But can we do a dwc3_phy_setup() without doing the soft reset of the controller first? > if (ret) > goto err0; > > - ret = dwc3_core_soft_reset(dwc); > + ret = dwc3_core_get_phy(dwc); we can get_phy in dwc3_core_init() as it will get called on resume(). This was the $subject of this patch. > if (ret) > goto err0; > > - ret = dwc3_phy_setup(dwc); > + ret = dwc3_core_soft_reset(dwc); > if (ret) > goto err0; > > And maybe we rename dwc3_phy_setup() to dwc3_phy_intf_config() just to > make the name match what the function actually does. Can you check that > it won't regress the case reported by Carlos? If that works, then we > would have to move BOTH dwc3_phy_setup() (dwc3_phy_intf_config()) and > dwc3_core_get_phy() outside of dwc3_core_init(), which would mean > duplicated code in suspend/resume handlers. > > I'm sure we can sort that out in another way; but the proper order is: > > -> initialize ULPI (if necessary) > -> get phy > -> soft reset > -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

by Roger Quadros

The USB PHYs should be requested only once during the life cycle of this driver. As dwc3_core_init() is called during system suspend/resume it will result in multiple calls to dwc3_core_get_phy() which is wrong. To prevent that let's move dwc3_core_get_phy() call outside dwc3_core_init(). Fixes: 541768b08a4 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys") Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13 Signed-off-by: Roger Quadros <rogerq(a)ti.com> --- drivers/usb/dwc3/core.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 0783250..1274251 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -722,8 +722,6 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc) dwc3_writel(dwc->regs, DWC3_GCTL, reg); } -static int dwc3_core_get_phy(struct dwc3 *dwc); - /** * dwc3_core_init - Low-level initialization of DWC3 Core * @dwc: Pointer to our controller context structure @@ -754,10 +752,6 @@ static int dwc3_core_init(struct dwc3 *dwc) dwc->maximum_speed = USB_SPEED_HIGH; } - ret = dwc3_core_get_phy(dwc); - if (ret) - goto err0; - ret = dwc3_core_soft_reset(dwc); if (ret) goto err0; @@ -1177,6 +1171,10 @@ static int dwc3_probe(struct platform_device *pdev) platform_set_drvdata(pdev, dwc); dwc3_cache_hwparams(dwc); + ret = dwc3_core_get_phy(dwc); + if (ret) + goto err0; + spin_lock_init(&dwc->lock); pm_runtime_set_active(dev); -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

7 years, 4 months

1
1
0 0

[Linux-stable-mirror] Patch "module: Issue warnings when tainting kernel" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled module: Issue warnings when tainting kernel to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: module-issue-warnings-when-tainting-kernel.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3205c36cf7d96024626f92d65f560035df1abcb2 Mon Sep 17 00:00:00 2001 From: Libor Pechacek <lpechacek(a)suse.com> Date: Wed, 13 Apr 2016 11:06:12 +0930 Subject: module: Issue warnings when tainting kernel From: Libor Pechacek <lpechacek(a)suse.com> commit 3205c36cf7d96024626f92d65f560035df1abcb2 upstream. While most of the locations where a kernel taint bit is set are accompanied with a warning message, there are two which set their bits silently. If the tainting module gets unloaded later on, it is almost impossible to tell what was the reason for setting the flag. Signed-off-by: Libor Pechacek <lpechacek(a)suse.com> Signed-off-by: Rusty Russell <rusty(a)rustcorp.com.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/module.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/kernel/module.c +++ b/kernel/module.c @@ -2888,8 +2888,12 @@ static int check_modinfo(struct module * return -ENOEXEC; } - if (!get_modinfo(info, "intree")) + if (!get_modinfo(info, "intree")) { + if (!test_taint(TAINT_OOT_MODULE)) + pr_warn("%s: loading out-of-tree module taints kernel.\n", + mod->name); add_taint_module(mod, TAINT_OOT_MODULE, LOCKDEP_STILL_OK); + } if (get_modinfo(info, "staging")) { add_taint_module(mod, TAINT_CRAP, LOCKDEP_STILL_OK); @@ -3054,6 +3058,8 @@ static int move_module(struct module *mo static int check_module_license_and_versions(struct module *mod) { + int prev_taint = test_taint(TAINT_PROPRIETARY_MODULE); + /* * ndiswrapper is under GPL by itself, but loads proprietary modules. * Don't use add_taint_module(), as it would prevent ndiswrapper from @@ -3072,6 +3078,9 @@ static int check_module_license_and_vers add_taint_module(mod, TAINT_PROPRIETARY_MODULE, LOCKDEP_NOW_UNRELIABLE); + if (!prev_taint && test_taint(TAINT_PROPRIETARY_MODULE)) + pr_warn("%s: module license taints kernel.\n", mod->name); + #ifdef CONFIG_MODVERSIONS if ((mod->num_syms && !mod->crcs) || (mod->num_gpl_syms && !mod->gpl_crcs) Patches currently in stable-queue which might be from lpechacek(a)suse.com are queue-4.4/module-issue-warnings-when-tainting-kernel.patch

7 years, 4 months

3
3
0 0

[Linux-stable-mirror] Patch "platform/x86: wmi: Call acpi_wmi_init() later" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: wmi: Call acpi_wmi_init() later to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: platform-x86-wmi-call-acpi_wmi_init-later.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 98b8e4e5c17bf87c1b18ed929472051dab39878c Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Wed, 3 Jan 2018 12:49:29 +0100 Subject: platform/x86: wmi: Call acpi_wmi_init() later From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> commit 98b8e4e5c17bf87c1b18ed929472051dab39878c upstream. Calling acpi_wmi_init() at the subsys_initcall() level causes ordering issues to appear on some systems and they are difficult to reproduce, because there is no guaranteed ordering between subsys_initcall() calls, so they may occur in different orders on different systems. In particular, commit 86d9f48534e8 (mm/slab: fix kmemcg cache creation delayed issue) exposed one of these issues where genl_init() and acpi_wmi_init() are both called at the same initcall level, but the former must run before the latter so as to avoid a NULL pointer dereference. For this reason, move the acpi_wmi_init() invocation to the initcall_sync level which should still be early enough for things to work correctly in the WMI land. Link: https://marc.info/?t=151274596700002&r=1&w=2 Reported-by: Jonathan McDowell <noodles(a)earth.li> Reported-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Tested-by: Jonathan McDowell <noodles(a)earth.li> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/platform/x86/wmi.c +++ b/drivers/platform/x86/wmi.c @@ -848,5 +848,5 @@ static void __exit acpi_wmi_exit(void) pr_info("Mapper unloaded\n"); } -subsys_initcall(acpi_wmi_init); +subsys_initcall_sync(acpi_wmi_init); module_exit(acpi_wmi_exit); Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are queue-4.9/platform-x86-wmi-call-acpi_wmi_init-later.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)mips.com> Date: Mon, 27 Nov 2017 09:33:03 +0000 Subject: MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task From: Maciej W. Rozycki <macro(a)mips.com> commit b67336eee3fcb8ecedc6c13e2bf88aacfa3151e2 upstream. Fix an API loophole introduced with commit 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS"), where the caller of prctl(2) is incorrectly allowed to make a change to CP0.Status.FR or CP0.Config5.FRE register bits even if CONFIG_MIPS_O32_FP64_SUPPORT has not been enabled, despite that an executable requesting the mode requested via ELF file annotation would not be allowed to run in the first place, or for n64 and n64 ABI tasks which do not have non-default modes defined at all. Add suitable checks to `mips_set_process_fp_mode' and bail out if an invalid mode change has been requested for the ABI in effect, even if the FPU hardware or emulation would otherwise allow it. Always succeed however without taking any further action if the mode requested is the same as one already in effect, regardless of whether any mode change, should it be requested, would actually be allowed for the task concerned. Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") Reviewed-by: Paul Burton <paul.burton(a)mips.com> Cc: James Hogan <james.hogan(a)mips.com> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17800/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/process.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/arch/mips/kernel/process.c +++ b/arch/mips/kernel/process.c @@ -683,6 +683,18 @@ int mips_set_process_fp_mode(struct task struct task_struct *t; int max_users; + /* If nothing to change, return right away, successfully. */ + if (value == mips_get_process_fp_mode(task)) + return 0; + + /* Only accept a mode change if 64-bit FP enabled for o32. */ + if (!IS_ENABLED(CONFIG_MIPS_O32_FP64_SUPPORT)) + return -EOPNOTSUPP; + + /* And only for o32 tasks. */ + if (IS_ENABLED(CONFIG_64BIT) && !test_thread_flag(TIF_32BIT_REGS)) + return -EOPNOTSUPP; + /* Check the value is valid */ if (value & ~known_bits) return -EOPNOTSUPP; Patches currently in stable-queue which might be from macro(a)mips.com are queue-4.9/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch queue-4.9/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch queue-4.9/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch queue-4.9/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch queue-4.9/mips-factor-out-nt_prfpreg-regset-access-helpers.patch queue-4.9/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch queue-4.9/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Guard against any partial write attempt with PTRACE_SETREGSET" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: Guard against any partial write attempt with PTRACE_SETREGSET to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)mips.com> Date: Mon, 11 Dec 2017 22:52:15 +0000 Subject: MIPS: Guard against any partial write attempt with PTRACE_SETREGSET From: Maciej W. Rozycki <macro(a)mips.com> commit dc24d0edf33c3e15099688b6bbdf7bdc24bf6e91 upstream. Complement commit d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write") and ensure that no partial register write attempt is made with PTRACE_SETREGSET, as we do not preinitialize any temporaries used to hold incoming register data and consequently random data could be written. It is the responsibility of the caller, such as `ptrace_regset', to arrange for writes to span whole registers only, so here we only assert that it has indeed happened. Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") Cc: James Hogan <james.hogan(a)mips.com> Cc: Paul Burton <Paul.Burton(a)mips.com> Cc: Alex Smith <alex(a)alex-smith.me.uk> Cc: Dave Martin <Dave.Martin(a)arm.com> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17926/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/ptrace.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -536,7 +536,15 @@ static int fpr_set_msa(struct task_struc return 0; } -/* Copy the supplied NT_PRFPREG buffer to the floating-point context. */ +/* + * Copy the supplied NT_PRFPREG buffer to the floating-point context. + * + * We optimize for the case where `count % sizeof(elf_fpreg_t) == 0', + * which is supposed to have been guaranteed by the kernel before + * calling us, e.g. in `ptrace_regset'. We enforce that requirement, + * so that we can safely avoid preinitializing temporaries for + * partial register writes. + */ static int fpr_set(struct task_struct *target, const struct user_regset *regset, unsigned int pos, unsigned int count, @@ -544,6 +552,8 @@ static int fpr_set(struct task_struct *t { int err; + BUG_ON(count % sizeof(elf_fpreg_t)); + /* XXX fcr31 */ init_fp_ctx(target); Patches currently in stable-queue which might be from macro(a)mips.com are queue-4.9/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch queue-4.9/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch queue-4.9/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch queue-4.9/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch queue-4.9/mips-factor-out-nt_prfpreg-regset-access-helpers.patch queue-4.9/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch queue-4.9/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From be07a6a1188372b6d19a3307ec33211fc9c9439d Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)mips.com> Date: Mon, 11 Dec 2017 22:54:33 +0000 Subject: MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA From: Maciej W. Rozycki <macro(a)mips.com> commit be07a6a1188372b6d19a3307ec33211fc9c9439d upstream. Fix a commit 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") public API regression, then activated by commit 1db1af84d6df ("MIPS: Basic MSA context switching support"), that caused the FCSR register not to be read or written for CONFIG_CPU_HAS_MSA kernel configurations (regardless of actual presence or absence of the MSA feature in a given processor) with ptrace(2) PTRACE_GETREGSET and PTRACE_SETREGSET requests nor recorded in core dumps. This is because with !CONFIG_CPU_HAS_MSA configurations the whole of `elf_fpregset_t' array is bulk-copied as it is, which includes the FCSR in one half of the last, 33rd slot, whereas with CONFIG_CPU_HAS_MSA configurations array elements are copied individually, and then only the leading 32 FGR slots while the remaining slot is ignored. Correct the code then such that only FGR slots are copied in the respective !MSA and MSA helpers an then the FCSR slot is handled separately in common code. Use `ptrace_setfcr31' to update the FCSR too, so that the read-only mask is respected. Retrieving a correct value of FCSR is important in debugging not only for the human to be able to get the right interpretation of the situation, but for correct operation of GDB as well. This is because the condition code bits in FSCR are used by GDB to determine the location to place a breakpoint at when single-stepping through an FPU branch instruction. If such a breakpoint is placed incorrectly (i.e. with the condition reversed), then it will be missed, likely causing the debuggee to run away from the control of GDB and consequently breaking the process of investigation. Fortunately GDB continues using the older PTRACE_GETFPREGS ptrace(2) request which is unaffected, so the regression only really hits with post-mortem debug sessions using a core dump file, in which case execution, and consequently single-stepping through branches is not possible. Of course core files created by buggy kernels out there will have the value of FCSR recorded clobbered, but such core files cannot be corrected and the person using them simply will have to be aware that the value of FCSR retrieved is not reliable. Which also means we can likely get away without defining a replacement API which would ensure a correct value of FSCR to be retrieved, or none at all. This is based on previous work by Alex Smith, extensively rewritten. Signed-off-by: Alex Smith <alex(a)alex-smith.me.uk> Signed-off-by: James Hogan <james.hogan(a)mips.com> Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> Fixes: 72b22bbad1e7 ("MIPS: Don't assume 64-bit FP registers for FP regset") Cc: Paul Burton <Paul.Burton(a)mips.com> Cc: Dave Martin <Dave.Martin(a)arm.com> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17928/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/ptrace.c | 47 +++++++++++++++++++++++++++++++++++----------- 1 file changed, 36 insertions(+), 11 deletions(-) --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -442,7 +442,7 @@ static int gpr64_set(struct task_struct /* * Copy the floating-point context to the supplied NT_PRFPREG buffer, * !CONFIG_CPU_HAS_MSA variant. FP context's general register slots - * correspond 1:1 to buffer slots. + * correspond 1:1 to buffer slots. Only general registers are copied. */ static int fpr_get_fpa(struct task_struct *target, unsigned int *pos, unsigned int *count, @@ -450,13 +450,14 @@ static int fpr_get_fpa(struct task_struc { return user_regset_copyout(pos, count, kbuf, ubuf, &target->thread.fpu, - 0, sizeof(elf_fpregset_t)); + 0, NUM_FPU_REGS * sizeof(elf_fpreg_t)); } /* * Copy the floating-point context to the supplied NT_PRFPREG buffer, * CONFIG_CPU_HAS_MSA variant. Only lower 64 bits of FP context's - * general register slots are copied to buffer slots. + * general register slots are copied to buffer slots. Only general + * registers are copied. */ static int fpr_get_msa(struct task_struct *target, unsigned int *pos, unsigned int *count, @@ -478,20 +479,29 @@ static int fpr_get_msa(struct task_struc return 0; } -/* Copy the floating-point context to the supplied NT_PRFPREG buffer. */ +/* + * Copy the floating-point context to the supplied NT_PRFPREG buffer. + * Choose the appropriate helper for general registers, and then copy + * the FCSR register separately. + */ static int fpr_get(struct task_struct *target, const struct user_regset *regset, unsigned int pos, unsigned int count, void *kbuf, void __user *ubuf) { + const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t); int err; - /* XXX fcr31 */ - if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t)) err = fpr_get_fpa(target, &pos, &count, &kbuf, &ubuf); else err = fpr_get_msa(target, &pos, &count, &kbuf, &ubuf); + if (err) + return err; + + err = user_regset_copyout(&pos, &count, &kbuf, &ubuf, + &target->thread.fpu.fcr31, + fcr31_pos, fcr31_pos + sizeof(u32)); return err; } @@ -499,7 +509,7 @@ static int fpr_get(struct task_struct *t /* * Copy the supplied NT_PRFPREG buffer to the floating-point context, * !CONFIG_CPU_HAS_MSA variant. Buffer slots correspond 1:1 to FP - * context's general register slots. + * context's general register slots. Only general registers are copied. */ static int fpr_set_fpa(struct task_struct *target, unsigned int *pos, unsigned int *count, @@ -507,13 +517,14 @@ static int fpr_set_fpa(struct task_struc { return user_regset_copyin(pos, count, kbuf, ubuf, &target->thread.fpu, - 0, sizeof(elf_fpregset_t)); + 0, NUM_FPU_REGS * sizeof(elf_fpreg_t)); } /* * Copy the supplied NT_PRFPREG buffer to the floating-point context, * CONFIG_CPU_HAS_MSA variant. Buffer slots are copied to lower 64 - * bits only of FP context's general register slots. + * bits only of FP context's general register slots. Only general + * registers are copied. */ static int fpr_set_msa(struct task_struct *target, unsigned int *pos, unsigned int *count, @@ -538,6 +549,8 @@ static int fpr_set_msa(struct task_struc /* * Copy the supplied NT_PRFPREG buffer to the floating-point context. + * Choose the appropriate helper for general registers, and then copy + * the FCSR register separately. * * We optimize for the case where `count % sizeof(elf_fpreg_t) == 0', * which is supposed to have been guaranteed by the kernel before @@ -550,18 +563,30 @@ static int fpr_set(struct task_struct *t unsigned int pos, unsigned int count, const void *kbuf, const void __user *ubuf) { + const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t); + u32 fcr31; int err; BUG_ON(count % sizeof(elf_fpreg_t)); - /* XXX fcr31 */ - init_fp_ctx(target); if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t)) err = fpr_set_fpa(target, &pos, &count, &kbuf, &ubuf); else err = fpr_set_msa(target, &pos, &count, &kbuf, &ubuf); + if (err) + return err; + + if (count > 0) { + err = user_regset_copyin(&pos, &count, &kbuf, &ubuf, + &fcr31, + fcr31_pos, fcr31_pos + sizeof(u32)); + if (err) + return err; + + ptrace_setfcr31(target, fcr31); + } return err; } Patches currently in stable-queue which might be from macro(a)mips.com are queue-4.9/mips-consistently-handle-buffer-counter-with-ptrace_setregset.patch queue-4.9/mips-disallow-outsized-ptrace_setregset-nt_prfpreg-regset-accesses.patch queue-4.9/mips-guard-against-any-partial-write-attempt-with-ptrace_setregset.patch queue-4.9/mips-also-verify-sizeof-elf_fpreg_t-with-ptrace_setregset.patch queue-4.9/mips-factor-out-nt_prfpreg-regset-access-helpers.patch queue-4.9/mips-validate-pr_set_fp_mode-prctl-2-requests-against-the-abi-of-the-task.patch queue-4.9/mips-fix-an-fcsr-access-api-regression-with-nt_prfpreg-and-msa.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror