Bug 1831399 (CVE-2020-10732) - CVE-2020-10732 kernel: uninitialized kernel data leak in userspace coredumps
Summary: CVE-2020-10732 kernel: uninitialized kernel data leak in userspace coredumps
Keywords:
Status: NEW
Alias: CVE-2020-10732
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1832059 1832060 1832062 1832063 1832634 1832061
Blocks: 1827001
TreeView+ depends on / blocked
 
Reported: 2020-05-05 05:18 UTC by Wade Mealing
Modified: 2020-06-18 22:34 UTC (History)
50 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the Linux kernel’s implementation of Userspace core dumps. This flaw allows an attacker with a local account to crash a trivial program and exfiltrate private kernel data.
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Wade Mealing 2020-05-05 05:18:28 UTC
A flaw was found in the Linux kernel implementation of userspace core dumps.  This flaw allows anyone with access to core dumps to see a small amount of private kernel data about the current running kernels internal state which could be used to further allow an attack to more reliably execute.  This information could be user processes or kernel state from previous executions.

References: 
 
https://github.com/google/kmsan/issues/76
https://twitter.com/grsecurity/status/1252558055629299712
https://github.com/ruscur/linux/commit/a95cdec9fa0c08e6eeb410d461c03af8fd1fef0a

Comment 3 Wade Mealing 2020-05-06 04:04:31 UTC
This flaw is rated as moderate, it can be a pretty useful information leak to defeat kaslr and
also be leveraged as part of another attack.

Comment 6 Wade Mealing 2020-05-06 04:33:56 UTC
There is no 'simple' fix to this.  The bug is located in the ELF executable loader.  If this code was to be blacklisted most executables would not run on the system making it operable for most use cases.

Comment 8 Wade Mealing 2020-05-06 04:44:33 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1832059]

Comment 11 Wade Mealing 2020-05-06 05:13:17 UTC
Mitigation:

Possible mitigation would be to disable core dumps system-wide by setting:

* hard core 0

In the  /etc/security/limits.conf file and restarting applications/services/processes which users may have access to or simply reboot the system.  This disables core dumps which may not be a suitable workaround in your environment.

Comment 15 Bhupesh Sharma 2020-05-15 06:32:22 UTC
The proposed fix has been accepted in linus-next tree (git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git):

commit aca969cacf07f41070d788ce2b8ca71f09d5207d
Author: Alexander Potapenko <glider@google.com>
Date:   Thu May 14 13:40:13 2020 +1000

    fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()

<..snip..>

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index fb7697029046..1a8b0c74f5b0 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1729,7 +1729,7 @@ static int fill_thread_core_info(struct elf_thread_core_info *t,
                    (!regset->active || regset->active(t->task, regset) > 0)) {
                        int ret;
                        size_t size = regset_size(t->task, regset);
-                       void *data = kmalloc(size, GFP_KERNEL);
+                       void *data = kzalloc(size, GFP_KERNEL);
                        if (unlikely(!data))
                                return 0;
                        ret = regset->get(t->task, regset,


Note You need to log in before you can comment on or make changes to this bug.