Tamas reported this UBSAN failure from fuzzing:

  (XEN) ================================================================================
  (XEN) UBSAN: Undefined behaviour in common/vsprintf.c:64:19
  (XEN) negation of -9223372036854775808 cannot be represented in type 'long long int':
  (XEN) ----[ Xen-4.19-unstable  x86_64  debug=y ubsan=y  Not tainted ]----
  ...
  (XEN) Xen call trace:
  (XEN)    [<ffff82d040307c1c>] R ubsan.c#ubsan_epilogue+0xa/0xd9
  (XEN)    [<ffff82d04030805d>] F __ubsan_handle_negate_overflow+0x99/0xce
  (XEN)    [<ffff82d04028868f>] F vsprintf.c#number+0x10a/0x93e
  (XEN)    [<ffff82d04028ac74>] F vsnprintf+0x19e2/0x1c56
  (XEN)    [<ffff82d04030a47a>] F console.c#vprintk_common+0x76/0x34d
  (XEN)    [<ffff82d04030a79e>] F printk+0x4d/0x4f
  (XEN)    [<ffff82d04040c42b>] F do_hvm_op+0x288e/0x28f5
  (XEN)    [<ffff82d04040d385>] F hvm_hypercall+0xad2/0x149a
  (XEN)    [<ffff82d0403cd072>] F vmx_vmexit_handler+0x1596/0x279c
  (XEN)    [<ffff82d0403d909b>] F vmx_asm_vmexit_handler+0xdb/0x200

The problem is an unsigned -> signed converstion because of a bad
formatter (%ld trying to format an unsigned long).

We could fix it by swapping to %lu, but this is a useless printk() even in
debug builds, so just drop it completely.

Reported-by: Tamas K Lengyel <tamas@tklengyel.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Wei Liu <wl@xen.org>
CC: Tamas K Lengyel <tamas@tklengyel.com>

-Wformat-signedness would catch this, but Xen isn't remotely close to being
able to have this warning enabled.
---
 xen/arch/x86/hvm/hvm.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e3bd9157d761..e8deeb022216 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5147,12 +5147,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
         break;
 
     default:
-    {
-        gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op);
         rc = -ENOSYS;
         break;
     }
-    }
 
     if ( rc == -ERESTART )
         rc = hypercall_create_continuation(__HYPERVISOR_hvm_op, "lh",

base-commit: cc6ba68edf6dcd18c3865e7d7c0f1ed822796426
-- 
2.30.2

On 30.01.2024 19:37, Andrew Cooper wrote:
> Tamas reported this UBSAN failure from fuzzing:
> 
>   (XEN) ================================================================================
>   (XEN) UBSAN: Undefined behaviour in common/vsprintf.c:64:19
>   (XEN) negation of -9223372036854775808 cannot be represented in type 'long long int':
>   (XEN) ----[ Xen-4.19-unstable  x86_64  debug=y ubsan=y  Not tainted ]----
>   ...
>   (XEN) Xen call trace:
>   (XEN)    [<ffff82d040307c1c>] R ubsan.c#ubsan_epilogue+0xa/0xd9
>   (XEN)    [<ffff82d04030805d>] F __ubsan_handle_negate_overflow+0x99/0xce
>   (XEN)    [<ffff82d04028868f>] F vsprintf.c#number+0x10a/0x93e
>   (XEN)    [<ffff82d04028ac74>] F vsnprintf+0x19e2/0x1c56
>   (XEN)    [<ffff82d04030a47a>] F console.c#vprintk_common+0x76/0x34d
>   (XEN)    [<ffff82d04030a79e>] F printk+0x4d/0x4f
>   (XEN)    [<ffff82d04040c42b>] F do_hvm_op+0x288e/0x28f5
>   (XEN)    [<ffff82d04040d385>] F hvm_hypercall+0xad2/0x149a
>   (XEN)    [<ffff82d0403cd072>] F vmx_vmexit_handler+0x1596/0x279c
>   (XEN)    [<ffff82d0403d909b>] F vmx_asm_vmexit_handler+0xdb/0x200
> 
> The problem is an unsigned -> signed converstion because of a bad
> formatter (%ld trying to format an unsigned long).
> 
> We could fix it by swapping to %lu, but this is a useless printk() even in
> debug builds, so just drop it completely.
> 
> Reported-by: Tamas K Lengyel <tamas@tklengyel.com>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

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