xen/gnttab: fix gnttab_acquire_resource()

Commit 9dc46386d8 ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddrs can legitimately be NULL in case
XENMEM_resource_grant_table_id_status was specified for a grant table
v1. This would result in crashes in debug builds due to
ASSERT_UNREACHABLE() triggering.

Check vaddrs only to be NULL in the rc == 0 case.

Expand the tests in tools/tests/resource to tickle this path, and verify that
using XENMEM_resource_grant_table_id_status on a v1 grant table fails.

Fixes: 9dc46386d8 ("gnttab: work around "may be used uninitialized" warning")
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com> # xen
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>

tools/tests/resource/test-resource.c

@@ -106,6 +106,21 @@ static void test_gnttab(uint32_t domid, unsigned int nr_frames,
     if ( rc )
         return fail("    Fail: Unmap grant table %d - %s\n",
                     errno, strerror(errno));
+
+    /*
+     * Verify that an attempt to map the status frames fails, as the domain is
+     * in gnttab v1 mode.
+     */
+    res = xenforeignmemory_map_resource(
+        fh, domid, XENMEM_resource_grant_table,
+        XENMEM_resource_grant_table_id_status, 0, 1,
+        (void **)&gnttab, PROT_READ | PROT_WRITE, 0);
+
+    if ( res )
+    {
+        fail("    Fail: Managed to map gnttab v2 status frames in v1 mode\n");
+        xenforeignmemory_unmap_resource(fh, res);
+    }
 }
 
 static void test_domain_configurations(void)

xen/common/grant_table.c

@@ -4140,7 +4140,7 @@ int gnttab_acquire_resource(
      * on non-error paths, and hence it needs setting to NULL at the top of the
      * function.  Leave some runtime safety.
      */
-    if ( !vaddrs )
+    if ( !rc && !vaddrs )
     {
         ASSERT_UNREACHABLE();
         rc = -ENODATA;