An integer overflow was found in the dp8393x NIC device emulation code of QEMU. It could occur while transmitting network packets in the dp8393x_do_transmit_packets() function in hw/net/dp8393x.c. The integer overflow could lead to a heap buffer overflow in a later function call of qemu_net_queue_append(). A malicious user in a linux/m68k guest (q800 machine) could exploit this flaw to carry out a denial of service attack by crashing the QEMU process on the host.
As it is not clear for which product this BZ is for, FWIW on RHEL QEMU isn't built with the m68k target.
Created qemu tracking bugs for this issue: Affects: epel-7 [bug 1899858] Affects: fedora-all [bug 1899857]
Hi Philippe, In reply to comment #1: > As it is not clear for which product this BZ is for, FWIW on RHEL QEMU isn't > built with the m68k target. This is intended to be a generic flaw bug, i.e., not tied to a specific product. I just created tracking bugs for Fedora/EPEL, as they both include m68k (and hence dp8393x) AFAICS. BTW, I'm not even sure this is eligible for CVE assignment as it may fall in the non-virtualization use case [1]. If so, I think we should consider this more of a regular hardening bug. What do you think? [1] https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case
In reply to comment #3: > BTW, I'm not even sure this is eligible for CVE assignment as it may fall in > the non-virtualization use case [1]. If so, I think we should consider this > more of a regular hardening bug. What do you think? No CVE assignment required for this bug, due to dp8393x device not being used by any KVM platform. Upstream patch: https://github.com/qemu/qemu/commit/915976bd98a9286efe6f2e573cb4f1360603adf9
External References: https://lists.nongnu.org/archive/html/qemu-devel/2020-12/msg00105.html