diff options
author | Raphael Norwitz <raphael.norwitz@nutanix.com> | 2022-01-17 04:12:34 +0000 |
---|---|---|
committer | Michael S. Tsirkin <mst@redhat.com> | 2022-02-04 09:07:43 -0500 |
commit | b906a23c33673f790a67dbd631a244387be77cb5 (patch) | |
tree | 0b3feab2ee662b87eee242065d4c26bc43a79d45 | |
parent | fa3d5483f0f4d4583b69ea7211c721418fca6704 (diff) | |
download | qemu-b906a23c33673f790a67dbd631a244387be77cb5.zip qemu-b906a23c33673f790a67dbd631a244387be77cb5.tar.gz qemu-b906a23c33673f790a67dbd631a244387be77cb5.tar.bz2 |
libvhost-user: prevent over-running max RAM slots
When VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS support was added to
libvhost-user, no guardrails were added to protect against QEMU
attempting to hot-add too many RAM slots to a VM with a libvhost-user
based backed attached.
This change adds the missing error handling by introducing a check on
the number of RAM slots the device has available before proceeding to
process the VHOST_USER_ADD_MEM_REG message.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Message-Id: <20220117041050.19718-6-raphael.norwitz@nutanix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
-rw-r--r-- | subprojects/libvhost-user/libvhost-user.c | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvhost-user/libvhost-user.c index 3f4d722..2a1fa00 100644 --- a/subprojects/libvhost-user/libvhost-user.c +++ b/subprojects/libvhost-user/libvhost-user.c @@ -705,6 +705,14 @@ vu_add_mem_reg(VuDev *dev, VhostUserMsg *vmsg) { return false; } + if (dev->nregions == VHOST_USER_MAX_RAM_SLOTS) { + close(vmsg->fds[0]); + vu_panic(dev, "failing attempt to hot add memory via " + "VHOST_USER_ADD_MEM_REG message because the backend has " + "no free ram slots available"); + return false; + } + /* * If we are in postcopy mode and we receive a u64 payload with a 0 value * we know all the postcopy client bases have been received, and we |