diff options
| author | Paolo Bonzini <pbonzini@redhat.com> | 2020-10-06 09:48:23 +0200 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2020-11-16 13:22:18 -0500 |
| commit | 42ccce19818e4e8fb55026f50b20d533cccc48f6 (patch) | |
| tree | fc7324c1a4c91e232539909657d065a157461847 /target/i386 | |
| parent | 3b12a7fd39307017c8968b8d05986a63b33752b5 (diff) | |
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>
Diffstat (limited to 'target/i386')
| -rw-r--r-- | target/i386/helper.c | 10 |
1 files changed, 4 insertions, 6 deletions
diff --git a/target/i386/helper.c b/target/i386/helper.c index 516ce0cad8..034f46bcc2 100644 --- a/target/i386/helper.c +++ b/target/i386/helper.c @@ -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) { |