--- /dev/null
+From 77f6ab8b7768cf5e6bdd0e72499270a0671506ee Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Wed, 28 Oct 2020 16:39:49 -0400
+Subject: don't dump the threads that had been already exiting when zapped.
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit 77f6ab8b7768cf5e6bdd0e72499270a0671506ee upstream.
+
+Coredump logics needs to report not only the registers of the dumping
+thread, but (since 2.5.43) those of other threads getting killed.
+
+Doing that might require extra state saved on the stack in asm glue at
+kernel entry; signal delivery logics does that (we need to be able to
+save sigcontext there, at the very least) and so does seccomp.
+
+That covers all callers of do_coredump(). Secondary threads get hit with
+SIGKILL and caught as soon as they reach exit_mm(), which normally happens
+in signal delivery, so those are also fine most of the time. Unfortunately,
+it is possible to end up with secondary zapped when it has already entered
+exit(2) (or, worse yet, is oopsing). In those cases we reach exit_mm()
+when mm->core_state is already set, but the stack contents is not what
+we would have in signal delivery.
+
+At least on two architectures (alpha and m68k) it leads to infoleaks - we
+end up with a chunk of kernel stack written into coredump, with the contents
+consisting of normal C stack frames of the call chain leading to exit_mm()
+instead of the expected copy of userland registers. In case of alpha we
+leak 312 bytes of stack. Other architectures (including the regset-using
+ones) might have similar problems - the normal user of regsets is ptrace
+and the state of tracee at the time of such calls is special in the same
+way signal delivery is.
+
+Note that had the zapper gotten to the exiting thread slightly later,
+it wouldn't have been included into coredump anyway - we skip the threads
+that have already cleared their ->mm. So let's pretend that zapper always
+loses the race. IOW, have exit_mm() only insert into the dumper list if
+we'd gotten there from handling a fatal signal[*]
+
+As the result, the callers of do_exit() that have *not* gone through get_signal()
+are not seen by coredump logics as secondary threads. Which excludes voluntary
+exit()/oopsen/traps/etc. The dumper thread itself is unaffected by that,
+so seccomp is fine.
+
+[*] originally I intended to add a new flag in tsk->flags, but ebiederman pointed
+out that PF_SIGNALED is already doing just what we need.
+
+Cc: stable@vger.kernel.org
+Fixes: d89f3847def4 ("[PATCH] thread-aware coredumps, 2.5.43-C3")
+History-tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
+Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/exit.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/kernel/exit.c
++++ b/kernel/exit.c
+@@ -516,7 +516,10 @@ static void exit_mm(void)
+ up_read(&mm->mmap_sem);
+
+ self.task = current;
+- self.next = xchg(&core_state->dumper.next, &self);
++ if (self.task->flags & PF_SIGNALED)
++ self.next = xchg(&core_state->dumper.next, &self);
++ else
++ self.task = NULL;
+ /*
+ * Implies mb(), the result of xchg() must be visible
+ * to core_state->dumper.
--- /dev/null
+From 06ad8d339524bf94b89859047822c31df6ace239 Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Thu, 5 Nov 2020 20:02:56 +0100
+Subject: drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[]
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
+
+The gma500 driver expects 3 pipelines in several it's IRQ functions.
+Accessing struct drm_device.vblank[], this fails with devices that only
+have 2 pipelines. An example KASAN report is shown below.
+
+ [ 62.267688] ==================================================================
+ [ 62.268856] BUG: KASAN: slab-out-of-bounds in psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
+ [ 62.269450] Read of size 1 at addr ffff8880012bc6d0 by task systemd-udevd/285
+ [ 62.269949]
+ [ 62.270192] CPU: 0 PID: 285 Comm: systemd-udevd Tainted: G E 5.10.0-rc1-1-default+ #572
+ [ 62.270807] Hardware name: /DN2800MT, BIOS MTCDT10N.86A.0164.2012.1213.1024 12/13/2012
+ [ 62.271366] Call Trace:
+ [ 62.271705] dump_stack+0xae/0xe5
+ [ 62.272180] print_address_description.constprop.0+0x17/0xf0
+ [ 62.272987] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
+ [ 62.273474] __kasan_report.cold+0x20/0x38
+ [ 62.273989] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
+ [ 62.274460] kasan_report+0x3a/0x50
+ [ 62.274891] psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
+ [ 62.275380] drm_irq_install+0x131/0x1f0
+ <...>
+ [ 62.300751] Allocated by task 285:
+ [ 62.301223] kasan_save_stack+0x1b/0x40
+ [ 62.301731] __kasan_kmalloc.constprop.0+0xbf/0xd0
+ [ 62.302293] drmm_kmalloc+0x55/0x100
+ [ 62.302773] drm_vblank_init+0x77/0x210
+
+Resolve the issue by only handling vblank entries up to the number of
+CRTCs.
+
+I'm adding a Fixes tag for reference, although the bug has been present
+since the driver's initial commit.
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
+Cc: Alan Cox <alan@linux.intel.com>
+Cc: Dave Airlie <airlied@redhat.com>
+Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
+Cc: dri-devel@lists.freedesktop.org
+Cc: stable@vger.kernel.org#v3.3+
+Link: https://patchwork.freedesktop.org/patch/msgid/20201105190256.3893-1-tzimmermann@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/gma500/psb_irq.c | 34 ++++++++++++----------------------
+ 1 file changed, 12 insertions(+), 22 deletions(-)
+
+--- a/drivers/gpu/drm/gma500/psb_irq.c
++++ b/drivers/gpu/drm/gma500/psb_irq.c
+@@ -350,6 +350,7 @@ int psb_irq_postinstall(struct drm_devic
+ {
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ unsigned long irqflags;
++ unsigned int i;
+
+ spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
+
+@@ -362,20 +363,12 @@ int psb_irq_postinstall(struct drm_devic
+ PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
+ PSB_WVDC32(0xFFFFFFFF, PSB_HWSTAM);
+
+- if (dev->vblank[0].enabled)
+- psb_enable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
+- else
+- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
+-
+- if (dev->vblank[1].enabled)
+- psb_enable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
+- else
+- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
+-
+- if (dev->vblank[2].enabled)
+- psb_enable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+- else
+- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
++ for (i = 0; i < dev->num_crtcs; ++i) {
++ if (dev->vblank[i].enabled)
++ psb_enable_pipestat(dev_priv, i, PIPE_VBLANK_INTERRUPT_ENABLE);
++ else
++ psb_disable_pipestat(dev_priv, i, PIPE_VBLANK_INTERRUPT_ENABLE);
++ }
+
+ if (dev_priv->ops->hotplug_enable)
+ dev_priv->ops->hotplug_enable(dev, true);
+@@ -388,6 +381,7 @@ void psb_irq_uninstall(struct drm_device
+ {
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ unsigned long irqflags;
++ unsigned int i;
+
+ spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
+
+@@ -396,14 +390,10 @@ void psb_irq_uninstall(struct drm_device
+
+ PSB_WVDC32(0xFFFFFFFF, PSB_HWSTAM);
+
+- if (dev->vblank[0].enabled)
+- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
+-
+- if (dev->vblank[1].enabled)
+- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
+-
+- if (dev->vblank[2].enabled)
+- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
++ for (i = 0; i < dev->num_crtcs; ++i) {
++ if (dev->vblank[i].enabled)
++ psb_disable_pipestat(dev_priv, i, PIPE_VBLANK_INTERRUPT_ENABLE);
++ }
+
+ dev_priv->vdc_irq_mask &= _PSB_IRQ_SGX_FLAG |
+ _PSB_IRQ_MSVDX_FLAG |
--- /dev/null
+From c350f8bea271782e2733419bd2ab9bf4ec2051ef Mon Sep 17 00:00:00 2001
+From: Chen Zhou <chenzhou10@huawei.com>
+Date: Thu, 12 Nov 2020 21:53:32 +0800
+Subject: selinux: Fix error return code in sel_ib_pkey_sid_slow()
+
+From: Chen Zhou <chenzhou10@huawei.com>
+
+commit c350f8bea271782e2733419bd2ab9bf4ec2051ef upstream.
+
+Fix to return a negative error code from the error handling case
+instead of 0 in function sel_ib_pkey_sid_slow(), as done elsewhere
+in this function.
+
+Cc: stable@vger.kernel.org
+Fixes: 409dcf31538a ("selinux: Add a cache for quicker retreival of PKey SIDs")
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/selinux/ibpkey.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/security/selinux/ibpkey.c
++++ b/security/selinux/ibpkey.c
+@@ -160,8 +160,10 @@ static int sel_ib_pkey_sid_slow(u64 subn
+ * is valid, it just won't be added to the cache.
+ */
+ new = kzalloc(sizeof(*new), GFP_ATOMIC);
+- if (!new)
++ if (!new) {
++ ret = -ENOMEM;
+ goto out;
++ }
+
+ new->psec.subnet_prefix = subnet_prefix;
+ new->psec.pkey = pkey_num;
projects / thirdparty / kernel / stable-queue.git / commitdiff
