linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [git pull] coredump infoleak fix
Date: Thu, 28 May 2020 09:02:55 +0200	[thread overview]
Message-ID: <20200528070255.GA790247@gmail.com> (raw)
In-Reply-To: <20200527213447.GH23230@ZenIV.linux.org.uk>


* Al Viro <viro@zeniv.linux.org.uk> wrote:

> 	xstate note on boxes with xsaves support can leak uninitialized data
> into coredumps
> 
> The following changes since commit 4e89b7210403fa4a8acafe7c602b6212b7af6c3b:
> 
>   fix multiplication overflow in copy_fdtable() (2020-05-19 18:29:36 -0400)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes
> 
> for you to fetch changes up to 9e4636545933131de15e1ecd06733538ae939b2f:
> 
>   copy_xstate_to_kernel(): don't leave parts of destination uninitialized (2020-05-27 17:06:31 -0400)
> 
> ----------------------------------------------------------------
> Al Viro (1):
>       copy_xstate_to_kernel(): don't leave parts of destination uninitialized
> 
>  arch/x86/kernel/fpu/xstate.c | 86 ++++++++++++++++++++++++--------------------
>  1 file changed, 48 insertions(+), 38 deletions(-)

Looks good to me.

I'm wondering, shouldn't we also zero-initialize the dump data to 
begin with? See the patch below (untested).

Thanks,

	Ingo

 fs/binfmt_elf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 13f25e241ac4..25d489bc9453 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1733,7 +1733,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,

  reply	other threads:[~2020-05-28  7:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 21:34 [git pull] coredump infoleak fix Al Viro
2020-05-28  7:02 ` Ingo Molnar [this message]
2020-05-28  7:05   ` Al Viro
2020-05-28  7:44     ` Ingo Molnar
2020-05-28 12:50       ` Al Viro
2020-05-29  9:35         ` Ingo Molnar
2020-05-28  7:29   ` [PATCH] fs/coredump/elf: Clean up fill_thread_core_info() Ingo Molnar
2020-05-28  7:40     ` [PATCH v2] " Ingo Molnar
2020-05-28 18:34   ` [git pull] coredump infoleak fix Linus Torvalds
2020-05-28 19:05     ` Al Viro
2020-05-28 19:09       ` Linus Torvalds
2020-05-28 19:17         ` Al Viro
2020-05-28 19:19           ` Linus Torvalds
2020-05-28 19:28             ` Al Viro
2020-05-29  9:39       ` Ingo Molnar
2020-05-31 18:05 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200528070255.GA790247@gmail.com \
    --to=mingo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).