From: Jamie Iles <jamie@nuviainc.com>
To: qemu-devel@nongnu.org
Cc: Jamie Iles <jamie@nuviainc.com>, lmichel@kalray.eu
Subject: [PATCH 0/2] Fix integer overflows in loading of large images
Date: Thu, 11 Nov 2021 14:11:39 +0000 [thread overview]
Message-ID: <20211111141141.3295094-1-jamie@nuviainc.com> (raw)
Most of the loader code currently uses a ssize_t or 64 bit integer type
to store image lengths, but many functions that handle loading return an
int with a negative value on error or length on success. Once an image
exceeds 2GB this will cause an integer overflow and so can end up
loading truncated images, silently failing to load an image (a 4GB image
would be interpreted as 0 bytes long).
This is unlikely to affect many deployments, but can manifest when
preloading RAM disks for example.
This builds upon 8975eb891fb6 ("hw/elf_ops.h: switch to ssize_t for elf
loader return type") to cover more of the generic loader.
Jamie Iles (2):
hw/core/loader: return image sizes as ssize_t
hw/core/loader: workaround read() size limit.
hw/arm/armv7m.c | 2 +-
hw/arm/boot.c | 8 +--
hw/core/generic-loader.c | 2 +-
hw/core/loader.c | 121 ++++++++++++++++++++++++---------------
hw/i386/x86.c | 2 +-
hw/riscv/boot.c | 5 +-
include/hw/loader.h | 55 +++++++++---------
7 files changed, 114 insertions(+), 81 deletions(-)
--
2.30.2
next reply other threads:[~2021-11-11 14:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 14:11 Jamie Iles [this message]
2021-11-11 14:11 ` [PATCH 1/2] hw/core/loader: return image sizes as ssize_t Jamie Iles
2021-11-11 14:20 ` Philippe Mathieu-Daudé
2021-11-12 8:25 ` Luc Michel
2021-11-15 4:24 ` Alistair Francis
2022-06-02 1:13 ` Alistair Francis
2021-11-11 14:11 ` [PATCH 2/2] hw/core/loader: workaround read() size limit Jamie Iles
2021-11-11 14:55 ` Philippe Mathieu-Daudé
2021-11-11 15:36 ` Jamie Iles
2021-11-11 15:43 ` Philippe Mathieu-Daudé
2021-11-11 15:55 ` Philippe Mathieu-Daudé
2021-11-11 17:04 ` Jamie Iles
2021-11-30 15:38 ` Jamie Iles
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=20211111141141.3295094-1-jamie@nuviainc.com \
--to=jamie@nuviainc.com \
--cc=lmichel@kalray.eu \
--cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.