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) If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-81627 https://www.cve.org/CVERecord?id=CVE-2026-81627 Please adjust the affected versions in the BTS as needed.
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