This is the start of the stable review cycle for the 4.14.12 release.
There are 14 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat Jan 6 12:08:52 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.12-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.12-rc1
Troy Kisky <troy.kisky(a)boundarydevices.com>
rtc: m41t80: remove unneeded checks from m41t80_sqw_set_rate
Troy Kisky <troy.kisky(a)boundarydevices.com>
rtc: m41t80: avoid i2c read in m41t80_sqw_is_prepared
Troy Kisky <troy.kisky(a)boundarydevices.com>
rtc: m41t80: avoid i2c read in m41t80_sqw_recalc_rate
Troy Kisky <troy.kisky(a)boundarydevices.com>
rtc: m41t80: fix m41t80_sqw_round_rate return value
Troy Kisky <troy.kisky(a)boundarydevices.com>
rtc: m41t80: m41t80_sqw_set_rate should return 0 on success
Steffen Klassert <steffen.klassert(a)secunet.com>
Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find."
Nick Desaulniers <ndesaulniers(a)google.com>
x86/process: Define cpu_tss_rw in same section as declaration
Thomas Gleixner <tglx(a)linutronix.de>
x86/pti: Switch to kernel CR3 at early in entry_SYSCALL_compat()
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/dumpstack: Print registers for first stack frame
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/dumpstack: Fix partial register dumps
Thomas Gleixner <tglx(a)linutronix.de>
x86/pti: Make sure the user/kernel PTEs match
Tom Lendacky <thomas.lendacky(a)amd.com>
x86/cpu, x86/pti: Do not enable PTI on AMD processors
Eric Biggers <ebiggers(a)google.com>
capabilities: fix buffer overread on very short xattr
Kees Cook <keescook(a)chromium.org>
exec: Weaken dumpability for secureexec
-------------
Diffstat:
Makefile | 4 +-
arch/x86/entry/entry_64_compat.S | 13 +++----
arch/x86/include/asm/unwind.h | 17 ++++++--
arch/x86/kernel/cpu/common.c | 4 +-
arch/x86/kernel/dumpstack.c | 31 ++++++++++-----
arch/x86/kernel/process.c | 2 +-
arch/x86/kernel/stacktrace.c | 2 +-
arch/x86/mm/pti.c | 3 +-
drivers/rtc/rtc-m41t80.c | 84 ++++++++++++++++++----------------------
fs/exec.c | 9 ++++-
net/xfrm/xfrm_policy.c | 29 ++++++++------
security/commoncap.c | 21 +++++-----
12 files changed, 120 insertions(+), 99 deletions(-)
From: Eric Biggers <ebiggers(a)google.com>
syzkaller triggered a NULL pointer dereference in crypto_remove_spawns()
via a program that repeatedly and concurrently requests AEADs
"authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)"
through AF_ALG, where the hashes are requested as "untested"
(CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this
causes the template to be instantiated for every request).
Although AF_ALG users really shouldn't be able to request an "untested"
algorithm, the NULL pointer dereference is actually caused by a
longstanding race condition where crypto_remove_spawns() can encounter
an instance which has had spawn(s) "grabbed" but hasn't yet been
registered, resulting in ->cra_users still being NULL.
We probably should properly initialize ->cra_users earlier, but that
would require updating many templates individually. For now just fix
the bug in a simple way that can easily be backported: make
crypto_remove_spawns() treat a NULL ->cra_users list as empty.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
crypto/algapi.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 9895cafcce7e..395b082d03a9 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -166,6 +166,18 @@ void crypto_remove_spawns(struct crypto_alg *alg, struct list_head *list,
spawn->alg = NULL;
spawns = &inst->alg.cra_users;
+
+ /*
+ * We may encounter an unregistered instance here, since
+ * an instance's spawns are set up prior to the instance
+ * being registered. An unregistered instance will have
+ * NULL ->cra_users.next, since ->cra_users isn't
+ * properly initialized until registration. But an
+ * unregistered instance cannot have any users, so treat
+ * it the same as ->cra_users being empty.
+ */
+ if (spawns->next == NULL)
+ break;
}
} while ((spawns = crypto_more_spawns(alg, &stack, &top,
&secondary_spawns)));
--
2.15.1
As mentioned on commit '88be58be886f ("drm/i915/fbdev:
Always forward hotplug events") we have real valid cases
of hotplugs where fbdev is not fully setup yet.
Unfortunately this remove the checkpoint after the sync point.
So probably we can live without it. Or we need a more robust
serialization.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
Fixes: a45b30a6c5db ("drm/i915/fbdev: Serialise early hotplug events with async fbdev config")
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Lukas Wunner <lukas(a)wunner.de>
Cc: jrg2718(a)gmail.com
Cc: stable(a)vger.kernel.org
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
---
drivers/gpu/drm/i915/intel_fbdev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index da48af11eb6b..7a6069b389f2 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -801,8 +801,7 @@ void intel_fbdev_output_poll_changed(struct drm_device *dev)
return;
intel_fbdev_sync(ifbdev);
- if (ifbdev->vma)
- drm_fb_helper_hotplug_event(&ifbdev->helper);
+ drm_fb_helper_hotplug_event(&ifbdev->helper);
}
void intel_fbdev_restore_mode(struct drm_device *dev)
--
2.13.6
On Thu, Jan 04, 2018 at 11:39:23PM +0000, Kenneth Graunke wrote:
> On Thursday, January 4, 2018 1:23:06 PM PST Chris Wilson wrote:
> > Quoting Kenneth Graunke (2018-01-04 19:38:05)
> > > Geminilake requires the 3D driver to select whether barriers are
> > > intended for compute shaders, or tessellation control shaders, by
> > > whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when
> > > switching pipelines. Failure to do this properly can result in GPU
> > > hangs.
> > >
> > > Unfortunately, this means it needs to switch mid-batch, so only
> > > userspace can properly set it. To facilitate this, the kernel needs
> > > to whitelist the register.
> > >
> > > Signed-off-by: Kenneth Graunke <kenneth(a)whitecape.org>
> > > Cc: stable(a)vger.kernel.org
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > > drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++++
> > > 2 files changed, 7 insertions(+)
> > >
> > > Hello,
> > >
> > > We unfortunately need to whitelist an extra register for GPU hang fix
> > > on Geminilake. Here's the corresponding Mesa patch:
> >
> > Thankfully it appears to be context saved. Has a w/a name been assigned
> > for this?
> > -Chris
>
> There doesn't appear to be one. The workaround page lists it, but there
> is no name. The register description has a note saying that you need to
> set this, but doesn't call it out as a workaround.
It mentions only BXT:ALL, but not mention to GLK.
Should we add to both then?
>
> That's why I put a generic comment, rather than the name.
On Display side we started using the row name for this case, to help
easily finding this later.
ex: "Display WA #0390: skl,kbl"
The number for this apparently is:
WA #0862
Maybe we could use this one to start
/* GT WA #0862: bxt,glk */
GT? GEM?
Unnamed WA #0862?
Thanks,
Rodrigo.
>
> --Ken
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx(a)lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Baoquan He <bhe(a)redhat.com>
Subject: mm/sparse.c: wrong allocation for mem_section
In 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") mem_section is allocated at runtime to save memory. While it allocates
the first dimension of array with sizeof(struct mem_section). It costs
extra memory, should be sizeof(struct mem_section*).
Fix it.
Link: http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-bhe@redhat.com
Fixes: 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y")
Signed-off-by: Baoquan He <bhe(a)redhat.com>
Tested-by: Dave Young <dyoung(a)redhat.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Andy Lutomirski <luto(a)amacapital.net>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Atsushi Kumagai <ats-kumagai(a)wm.jp.nec.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/sparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/sparse.c~mm-sparsec-wrong-allocation-for-mem_section mm/sparse.c
--- a/mm/sparse.c~mm-sparsec-wrong-allocation-for-mem_section
+++ a/mm/sparse.c
@@ -211,7 +211,7 @@ void __init memory_present(int nid, unsi
if (unlikely(!mem_section)) {
unsigned long size, align;
- size = sizeof(struct mem_section) * NR_SECTION_ROOTS;
+ size = sizeof(struct mem_section*) * NR_SECTION_ROOTS;
align = 1 << (INTERNODE_CACHE_SHIFT);
mem_section = memblock_virt_alloc(size, align);
}
_