From: Janosch Frank <frankja@linux.ibm.com>
To: Thomas Huth <thuth@redhat.com>,
qemu-s390x@nongnu.org, David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org,
Richard Henderson <richard.henderson@linaro.org>,
Ilya Leoshkevich <iii@linux.ibm.com>
Subject: Re: [PATCH] target/s390x/arch_dump: Fix memory corruption in s390x_write_elf64_notes()
Date: Tue, 14 Feb 2023 16:01:08 +0100 [thread overview]
Message-ID: <ef30d5bf-6e8d-e038-d091-05f2ef607c5c@linux.ibm.com> (raw)
In-Reply-To: <20230214141056.680969-1-thuth@redhat.com>
On 2/14/23 15:10, Thomas Huth wrote:
> "note_size" can be smaller than sizeof(note), so unconditionally calling
> memset(notep, 0, sizeof(note)) could cause a memory corruption here in
> case notep has been allocated dynamically, thus let's use note_size as
> length argument for memset() instead.
>
> Fixes: 113d8f4e95 ("s390x: pv: Add dump support")
> Signed-off-by: Thomas Huth <thuth@redhat.com>
This was found because a machine was used that has PV support but
doesn't have the PV dump support (I currently don't have access to a
previous generation machine). In that case the size of the PV cpu note
is reported as 0 but it's still being written / processed.
I added proper checks for dump support on my todo list so we can avoid
writing empty notes. However it's easier said than done since "dump
support" is actually a combination of KVM, QEMU, the machine AND a bit
in the SE header that allows dumping. Additionally we need to report the
size of the notes way before we start the PV dump process where we get
told if the machine is allowed to dump.
Thanks for helping with the debug effort and creating a patch Thomas!
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Also:
Reported-by: Sebastian Mitterle <smitterl@redhat.com>
> ---
> target/s390x/arch_dump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/s390x/arch_dump.c b/target/s390x/arch_dump.c
> index a2329141e8..a7c44ba49d 100644
> --- a/target/s390x/arch_dump.c
> +++ b/target/s390x/arch_dump.c
> @@ -248,7 +248,7 @@ static int s390x_write_elf64_notes(const char *note_name,
> notep = g_malloc(note_size);
> }
>
> - memset(notep, 0, sizeof(note));
> + memset(notep, 0, note_size);
>
> /* Setup note header data */
> notep->hdr.n_descsz = cpu_to_be32(content_size);
prev parent reply other threads:[~2023-02-14 15:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-14 14:10 [PATCH] target/s390x/arch_dump: Fix memory corruption in s390x_write_elf64_notes() Thomas Huth
2023-02-14 14:58 ` Philippe Mathieu-Daudé
2023-02-15 5:20 ` Thomas Huth
2023-02-15 5:49 ` Thomas Huth
2023-02-14 15:01 ` Janosch Frank [this message]
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=ef30d5bf-6e8d-e038-d091-05f2ef607c5c@linux.ibm.com \
--to=frankja@linux.ibm.com \
--cc=david@redhat.com \
--cc=iii@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/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).