On 9/20/26 01:18, Moritz Mühlenhoff wrote:
Source: qemu
X-Debbugs-CC: [email protected]
Severity: important
Tags: security
Hi,
The following vulnerability was published for qemu.
CVE-2026-81627[0]:
| A flaw was found in QEMU. The VAPIC setup hypercall in
| hw/i386/vapic.c does not validate that the writable RAM alias
| remains within the option ROM window. A privileged guest user on a
| Q35/KVM machine can position this alias over locked SMRAM, bypassing
| chipset D_LCK protection and injecting code into System Management
| Mode memory.
https://gitlab.com/qemu-project/qemu/-/work_items/4206
Fixed by:
https://gitlab.com/qemu-project/qemu/-/commit/d61c8a6fb7388486353aa267ba0d75b098f16662
(master)
This will be fixed in the next batch of qemu stable series,
scheduled to be released on Sep-28 - this and a few other
issues too.
Should I address this one in debian now via a security update,
with the next stable point release to be included in next
debian trixie point release?
Or is it okay to wait - either for the next upstream stable
to be released as a security update, or in regular next
trixie point release?
https://gitlab.com/qemu-project/qemu/-/commits/staging-10.0 is
the current queue for upstream 10.0.14, and commit c9cfa874
"vapic: confine the VAPIC region to 0xc0000..0xe0000" in in
that list too.
There's also fixes for CVE-2026-12080, CVE-2026-66899, CVE-2026-66020,
CVE-2026-84788, CVE-2026-77913, CVE-2026-16271 in there, among others.
Thanks,
/mjt
