qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug 1878645] Re: null-ptr dereference in tcg_handle_interrupt


From: Alex Bennée
Subject: Re: [Bug 1878645] Re: null-ptr dereference in tcg_handle_interrupt
Date: Mon, 29 Jun 2020 20:00:44 +0100
User-agent: mu4e 1.5.3; emacs 28.0.50

Alexander Bulekov <1878645@bugs.launchpad.net> writes:

> I don't think this is a qtest-specific error: 
> cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio
> o/4 0xcf8 0x8400f841
> o/4 0xcfc 0xaa215d6d
> o/4 0x6d30 0x2ef8ffbe
> o/1 0xb2 0x20
> EOF
>
> ...
> Segmentation fault

Both this and the qtest have the same problem of depending on
current_cpu which is a TLS variable which will never be correct from the
qtest or monitor context. There are only a few other cases.

sun4m:cpu_halt_signal does:

    if (level && current_cpu) {
        cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT);
    }

pxa2xx:pxa2xx_pwrmode_write does a bare:

    /* Suspend */
    cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT);

but given the context has a CPUARMState *env it could arguably use that
to derive current_cpu but as it's only triggered by a system register
write you can't actually trigger from a monitor/qtest command.

I would suggest either:

        } else if (current_cpu) {
            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
        }

or possibly:

        } else {
            cpu_interrupt(current_cpu ? current_cpu : first_cpu, 
CPU_INTERRUPT_SMI);
        }

if you really care about triggering a real IRQ from outside the CPU context.

-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]