summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRaphael Norwitz2022-01-17 05:12:34 +0100
committerMichael S. Tsirkin2022-02-04 15:07:43 +0100
commitb906a23c33673f790a67dbd631a244387be77cb5 (patch)
tree0b3feab2ee662b87eee242065d4c26bc43a79d45
parentlibvhost-user: fix VHOST_USER_REM_MEM_REG not closing the fd (diff)
downloadqemu-b906a23c33673f790a67dbd631a244387be77cb5.tar.gz
qemu-b906a23c33673f790a67dbd631a244387be77cb5.tar.xz
qemu-b906a23c33673f790a67dbd631a244387be77cb5.zip
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.c8
1 files changed, 8 insertions, 0 deletions
diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvhost-user/libvhost-user.c
index 3f4d7221ca..2a1fa00a44 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