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>
---
 subprojects/libvhost-user/libvhost-user.c | 8 ++++++++
 1 file changed, 8 insertions(+)

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
-- 
2.20.1

On 17.01.22 05:12, Raphael Norwitz wrote:
> 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>
> ---
>  subprojects/libvhost-user/libvhost-user.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> 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");

Maybe simply "VHOST_USER_ADD_MEM_REG failed because there are no free
ram slots"

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb

On 1/17/22 09:20, David Hildenbrand wrote:
> On 17.01.22 05:12, Raphael Norwitz wrote:
>> 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>
>> ---
>>  subprojects/libvhost-user/libvhost-user.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)

>> +    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");
> 
> Maybe simply "VHOST_USER_ADD_MEM_REG failed because there are no free
> ram slots"
> 
> Reviewed-by: David Hildenbrand <david@redhat.com>
> 

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>