target/i386: avoid theoretical leak on MCE injection

g_strdup_printf is used twice to write to the same variable, which
can theoretically cause a leak.  In practice, it is extremely
unlikely that a guest is seeing a recursive MCE and has disabled
CR4.MCE between the first and the second error, but we can fix it
and we can also make a slight improvement on the logic: CR4.MCE=0
causes a triple fault even for a non-recursive machine check, so
let's place its test first.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This commit is contained in:
Paolo Bonzini 2020-10-06 09:48:23 +02:00
parent 3b12a7fd39
commit 42ccce1981
1 changed files with 4 additions and 6 deletions

View File

@ -908,16 +908,14 @@ static void do_inject_x86_mce(CPUState *cs, run_on_cpu_data data)
return;
}
if (recursive) {
need_reset = true;
msg = g_strdup_printf("CPU %d: Previous MCE still in progress, "
"raising triple fault", cs->cpu_index);
}
if (!(cenv->cr[4] & CR4_MCE_MASK)) {
need_reset = true;
msg = g_strdup_printf("CPU %d: MCE capability is not enabled, "
"raising triple fault", cs->cpu_index);
} else if (recursive) {
need_reset = true;
msg = g_strdup_printf("CPU %d: Previous MCE still in progress, "
"raising triple fault", cs->cpu_index);
}
if (need_reset) {