January 2018 - Linux-stable-mirror

[Linux-stable-mirror] [PATCH for 4.16 01/11] Fix: membarrier: add missing preempt off around smp_call_function_many

by Mathieu Desnoyers

smp_call_function_many requires disabling preemption around the call. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> CC: Linus Torvalds <torvalds(a)linux-foundation.org> CC: Peter Zijlstra <peterz(a)infradead.org> CC: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> CC: Boqun Feng <boqun.feng(a)gmail.com> CC: Andrew Hunter <ahh(a)google.com> CC: Maged Michael <maged.michael(a)gmail.com> CC: Avi Kivity <avi(a)scylladb.com> CC: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> CC: Paul Mackerras <paulus(a)samba.org> CC: Michael Ellerman <mpe(a)ellerman.id.au> CC: Dave Watson <davejwatson(a)fb.com> CC: Thomas Gleixner <tglx(a)linutronix.de> CC: Ingo Molnar <mingo(a)redhat.com> CC: "H. Peter Anvin" <hpa(a)zytor.com> CC: Andrea Parri <parri.andrea(a)gmail.com> CC: <stable(a)vger.kernel.org> #v4.14 --- kernel/sched/membarrier.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c index dd7908743dab..9bcbacba82a8 100644 --- a/kernel/sched/membarrier.c +++ b/kernel/sched/membarrier.c @@ -89,7 +89,9 @@ static int membarrier_private_expedited(void) rcu_read_unlock(); } if (!fallback) { + preempt_disable(); smp_call_function_many(tmpmask, ipi_mb, NULL, 1); + preempt_enable(); free_cpumask_var(tmpmask); } cpus_read_unlock(); -- 2.11.0

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH] drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()

by Boris Brezillon

When saving BOs in the hang state we skip one entry of the kernel_state->bo[] array, thus leaving it to NULL. This leads to a NULL pointer dereference when, later in this function, we iterate over all BOs to check their ->madv state. Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs") Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> --- drivers/gpu/drm/vc4/vc4_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c index 6c32c89a83a9..19ac7fe0e5db 100644 --- a/drivers/gpu/drm/vc4/vc4_gem.c +++ b/drivers/gpu/drm/vc4/vc4_gem.c @@ -208,7 +208,7 @@ vc4_save_hang_state(struct drm_device *dev) kernel_state->bo[j + prev_idx] = &bo->base.base; j++; } - prev_idx = j + 1; + prev_idx = j; } if (exec[0]) -- 2.11.0

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] v4.4.111 build: 0 failures 0 warnings (v4.4.111)

by Build bot for Mark Brown

Tree/Branch: v4.4.111 Git describe: v4.4.111 Commit: c5ae3a6aa1 Linux 4.4.111 Build Time: 79 min 24 sec Passed: 9 / 9 (100.00 %) Failed: 0 / 9 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

6 years, 11 months

1
0
0 0

[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

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2018