The max_message_size field of the output gets filled only when the flags
field is non-zero. Don't copy back uninitialized data to guest context.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -1405,7 +1405,8 @@ fill_ring_data(const struct domain *curr
         rcu_unlock_domain(dst_d);
 
     if ( !ret && (__copy_field_to_guest(data_ent_hnd, &ent, flags) ||
-                  __copy_field_to_guest(data_ent_hnd, &ent, max_message_size)) )
+                  (ent.flags &&
+                   __copy_field_to_guest(data_ent_hnd, &ent, max_message_size))) )
         return -EFAULT;
 
     return ret;

On Thu, Jan 14, 2021 at 03:01:06PM +0100, Jan Beulich wrote:
> The max_message_size field of the output gets filled only when the flags
> field is non-zero. Don't copy back uninitialized data to guest context.

I'm afraid I'm missing something. AFAICT ent gets filled from the
user-space contents of data_ent_hnd that's copied from user-space at
the top of the function, so there's no leak from hypervisor stack in
the return path?

Thanks, Roger.

On 14.01.2021 17:59, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at 03:01:06PM +0100, Jan Beulich wrote:
>> The max_message_size field of the output gets filled only when the flags
>> field is non-zero. Don't copy back uninitialized data to guest context.
> 
> I'm afraid I'm missing something. AFAICT ent gets filled from the
> user-space contents of data_ent_hnd that's copied from user-space at
> the top of the function,

Oh, I managed to overlook this multiple time, so ...

> so there's no leak from hypervisor stack in
> the return path?

... yes indeed. Withdrawing the patch.

Thanks for noticing,
Jan