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>