Comment 3 for bug 1914883

Hi,
thanks for the report, this seems to keep on giving.

Initially we had:

 128 qemu (1:4.2-3ubuntu6.4) focal-security; urgency=medium

 177 * SECURITY UPDATE: out-of-bounds access via msi-x mmio operation
 178 - debian/patches/ubuntu/CVE-2020-13754-1.patch: revert accepting
 179 mismatching sizes in memory_region_access_valid in memory.c.
 180 - debian/patches/ubuntu/CVE-2020-13754-2.patch: accept byte and word
 181 access to core ACPI registers in hw/acpi/core.c.
 182 - CVE-2020-13754

But something close to the issue you mentioned was spotted quickly and resolved in

 113 qemu (1:4.2-3ubuntu6.5) focal; urgency=medium

 118 - as part of the stabilization this also fixes an
 119 riscv emulation issue due to the CVE-2020-13754 fixes via
 120 d/p/ubuntu/hw-riscv-Allow-64-bit-access-to-SiFive-CLINT.patch

Yet your hint made me wonder "what else" this might have been found to be broken and that is quite a list.

So we have already (in Focal):
https://github.com/qemu/qemu/commit/70b78d4e71494c90d2ccb40381336bc9b9a22f79

But in the meantime there also is this list::
https://github.com/qemu/qemu/commit/5c49f7ee3b98316850de6a33952a4ac47701c118 (== ab3d207fe8 but one is from a stable branch)
https://github.com/qemu/qemu/commit/62a9b228b5fefe0f9e364dfeaf3c65022c63cdb9
https://github.com/qemu/qemu/commit/3059344f01e1bf9625570ef2e8396fa011e9431d
https://github.com/qemu/qemu/commit/e0cf02ce680f11893aca9642e76d6ae68b9375af
https://github.com/qemu/qemu/commit/dba04c3488c4699f5afe96f66e448b1d447cf3fb
https://github.com/qemu/qemu/commit/8e67fda2dd6202ccec093fda561107ba14830a17

Related but not strictly needed:
https://github.com/qemu/qemu/commit/21786c7e59847b1612406ff394958f22e5b323f8

Qemu 5.2 has all the known fixes that exist so far, thereby this is fixed in Hirsute.
The CVE-2020-13754 was released to X/B/F (and G, but before G released).
So IMHO X,B,G seem to need the fixups mentioned above, F needs the same minus the one I already added.

This will eventually need to be pushed to -security, also there is a chance that Mark (doing the security update) and/pr the security community had context/discussions about this.
For now I'll assign this to Mark for his input on this.

While we wait for Marks awnser @nathan - could you outline steps to reproduce an issue related to this. For the SRU one would want commands that fail without the fix and work once applied.
I assume you'd have some RiscV Emulation steps we could use for that?