summary refs log tree commit diff stats
path: root/results/classifier/105/KVM/1914353
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/105/KVM/1914353')
-rw-r--r--results/classifier/105/KVM/191435374
1 files changed, 74 insertions, 0 deletions
diff --git a/results/classifier/105/KVM/1914353 b/results/classifier/105/KVM/1914353
new file mode 100644
index 00000000..c39aca8a
--- /dev/null
+++ b/results/classifier/105/KVM/1914353
@@ -0,0 +1,74 @@
+KVM: 0.974
+graphic: 0.775
+other: 0.747
+device: 0.739
+instruction: 0.720
+socket: 0.622
+mistranslation: 0.616
+vnc: 0.528
+semantic: 0.523
+network: 0.506
+boot: 0.416
+assembly: 0.347
+
+QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID
+
+Via [qemu-security] list
+
++-- On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote --+
+| On 1/31/21 11:34 AM, Philippe Mathieu-Daudé wrote:
+| > Per the ARM Generic Interrupt Controller Architecture specification
+| > (document "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit,
+| > not 10:
+| >
+| >    - Table 4-21 GICD_SGIR bit assignments
+| >
+| >    The Interrupt ID of the SGI to forward to the specified CPU
+| >    interfaces. The value of this field is the Interrupt ID, in
+| >    the range 0-15, for example a value of 0b0011 specifies
+| >    Interrupt ID 3.
+| >
+...
+| > Correct the irq mask to fix an undefined behavior (which eventually
+| > lead to a heap-buffer-overflow, see [Buglink]):
+| >
+| >    $ echo 'writel 0x8000f00 0xff4affb0' | qemu-system-aarch64 -M virt,accel=qtest -qtest stdio
+| >    [I 1612088147.116987] OPENED
+| >  [R +0.278293] writel 0x8000f00 0xff4affb0
+| >  ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds for type 'uint8_t [16][8]'
+| >  SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1498:13
+| >
+| > Cc: <email address hidden>
+| > Fixes: 9ee6e8bb853 ("ARMv7 support.")
+| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913916
+| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913917
+...
+
+On 210202 1221, Peter Maydell wrote:
+> In both cases the overrun is on the first writel to 0x8000f00,
+> but the fuzzer has for some reason not reported that but instead
+> blundered on until it happens to trigger some other issue that
+> resulted from the memory corruption it induced with the first write.
+>
+...
+> On the CVE:
+>
+> Since this can affect systems using KVM, this is a security bug for
+> us. However, it only affects an uncommon configuration:
+> you are only vulnerable if you are using "kernel-irqchip=off"
+> (the default is 'on', and turning it off is an odd thing to do).
+>
+> thanks
+> -- PMM
+>
+
+Upstream patch:
+  -> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00709.html
+
+CVE requested.
+
+'CVE-2021-20221' assigned by Red Hat Inc.
+
+Fix has been included here:
+https://gitlab.com/qemu-project/qemu/-/commit/edfe2eb4360cde4ed5d95bd
+