Headline
CVE-2020-15859: [PATCH] e1000e: using bottom half to send packets
QEMU 4.2.0 has a use-after-free in hw/net/e1000e_core.c because a guest OS user can trigger an e1000e packet with the data’s address set to the e1000e’s MMIO address.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
From:
Li Qiang
Subject:
[PATCH] e1000e: using bottom half to send packets
Date:
Thu, 16 Jul 2020 09:14:53 -0700
Alexander Bulekov reported a UAF bug related e1000e packets send.
–>https://bugs.launchpad.net/qemu/+bug/1886362
This is because the guest trigger a e1000e packet send and set the data’s address to e1000e’s MMIO address. So when the e1000e do DMA it will write the MMIO again and trigger re-entrancy and finally causes this UAF.
Paolo suggested to use a bottom half whenever MMIO is doing complicate things in here: –>https://lists.nongnu.org/archive/html/qemu-devel/2020-07/msg03342.html
Reference here: ‘The easiest solution is to delay processing of descriptors to a bottom half whenever MMIO is doing something complicated. This is also better for latency because it will free the vCPU thread more quickly and leave the work to the I/O thread.’
This patch fixes this UAF.
Signed-off-by: Li Qiang [email protected]
hw/net/e1000e_core.c | 25 ++++++++++++++++±------- hw/net/e1000e_core.h | 2 ++ 2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c index bcd186cac5…6165b04b68 100644 — a/hw/net/e1000e_core.c +++ b/hw/net/e1000e_core.c @@ -2423,32 +2423,27 @@ e1000e_set_dbal(E1000ECore *core, int index, uint32_t val) static void e1000e_set_tctl(E1000ECore *core, int index, uint32_t val) {
E1000E_TxRing txr; core->mac[index] = val;
if (core->mac[TARC0] & E1000_TARC_ENABLE) {
e1000e\_tx\_ring\_init(core, &txr, 0);
e1000e\_start\_xmit(core, &txr);
qemu\_bh\_schedule(core->tx\[0\].tx\_bh);
}
if (core->mac[TARC1] & E1000_TARC_ENABLE) {
e1000e\_tx\_ring\_init(core, &txr, 1);
e1000e\_start\_xmit(core, &txr);
} }qemu\_bh\_schedule(core->tx\[1\].tx\_bh);
static void e1000e_set_tdt(E1000ECore *core, int index, uint32_t val) {
E1000E_TxRing txr; int qidx = e1000e_mq_queue_idx(TDT, index); uint32_t tarc_reg = (qidx == 0) ? TARC0 : TARC1;
core->mac[index] = val & 0xffff;
if (core->mac[tarc_reg] & E1000_TARC_ENABLE) {
e1000e\_tx\_ring\_init(core, &txr, qidx);
e1000e\_start\_xmit(core, &txr);
} }qemu\_bh\_schedule(core->tx\[qidx\].tx\_bh);
@@ -3322,6 +3317,16 @@ e1000e_vm_state_change(void *opaque, int running, RunState state) } }
+static void e1000e_core_tx_bh(void *opaque) +{
- struct e1000e_tx *tx = opaque;
- E1000ECore *core = tx->core;
- E1000E_TxRing txr;
- e1000e_tx_ring_init(core, &txr, tx - &core->tx[0]);
- e1000e_start_xmit(core, &txr); +}
void e1000e_core_pci_realize(E1000ECore *core, const uint16_t *eeprom_templ, @@ -3340,6 +3345,8 @@ e1000e_core_pci_realize(E1000ECore *core, for (i = 0; i < E1000E_NUM_QUEUES; i++) { net_tx_pkt_init(&core->tx[i].tx_pkt, core->owner, E1000E_MAX_TX_FRAGS, core->has_vnet);
core->tx\[i\].core = core;
core->tx\[i\].tx\_bh = qemu\_bh\_new(e1000e\_core\_tx\_bh, &core->tx\[i\]);
}
net_rx_pkt_init(&core->rx_pkt, core->has_vnet); @@ -3367,6 +3374,8 @@ e1000e_core_pci_uninit(E1000ECore *core) for (i = 0; i < E1000E_NUM_QUEUES; i++) { net_tx_pkt_reset(core->tx[i].tx_pkt); net_tx_pkt_uninit(core->tx[i].tx_pkt);
qemu\_bh\_delete(core->tx\[i\].tx\_bh);
core->tx\[i\].tx\_bh = NULL;
}
net_rx_pkt_uninit(core->rx_pkt); diff --git a/hw/net/e1000e_core.h b/hw/net/e1000e_core.h index aee32f7e48…94ddc6afc2 100644 — a/hw/net/e1000e_core.h +++ b/hw/net/e1000e_core.h @@ -77,6 +77,8 @@ struct E1000Core { unsigned char sum_needed; bool cptse; struct NetTxPkt *tx_pkt;
QEMUBH \*tx\_bh;
E1000ECore \*core;
} tx[E1000E_NUM_QUEUES];
struct NetRxPkt *rx_pkt; – 2.17.1
[PATCH] e1000e: using bottom half to send packets, Li Qiang <=
- Re: [PATCH] e1000e: using bottom half to send packets, Jason Wang, 2020/07/16
- Re: [PATCH] e1000e: using bottom half to send packets, Li Qiang, 2020/07/17
- Re: [PATCH] e1000e: using bottom half to send packets, Jason Wang, 2020/07/17
- Re: [PATCH] e1000e: using bottom half to send packets, Li Qiang, 2020/07/17
- Re: [PATCH] e1000e: using bottom half to send packets, Jason Wang, 2020/07/20
- Re: [PATCH] e1000e: using bottom half to send packets, Li Qiang, 2020/07/20
- Re: [PATCH] e1000e: using bottom half to send packets, Peter Maydell, 2020/07/17
- Re: [PATCH] e1000e: using bottom half to send packets, Jason Wang, 2020/07/20
- Re: [PATCH] e1000e: using bottom half to send packets, Li Qiang, 2020/07/17
- Re: [PATCH] e1000e: using bottom half to send packets, Jason Wang, 2020/07/16
Prev by Date: Re: [PATCH v3 7/9] tz-ppc: add dummy read/write methods
Next by Date: Re: [PATCH for-5.1] qapi: Fix visit_type_STRUCT() not to fail for null object
Previous by thread: Re: [PATCH v3 7/9] tz-ppc: add dummy read/write methods
Next by thread: Re: [PATCH] e1000e: using bottom half to send packets
Index(es):
- Date
- Thread
Related news
Gentoo Linux Security Advisory 202208-27 - Multiple vulnerabilities have been discovered in QEMU, the worst of which could result in remote code execution (guest sandbox escape). Versions less than 7.0.0 are affected.
An update for the virt:rhel and virt-devel:rhel modules is now available for Red Hat Enterprise Linux 8. Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2020-15859: QEMU: net: e1000e: use-after-free while sending packets * CVE-2021-3592: QEMU: slirp: invalid pointer initialization may lead to information disclosure (bootp) * CVE-2021-3593: QEMU: slirp: invalid pointer initialization may lead to information disclosure (udp6) * CVE-2021-3594: QEMU: slirp: invalid pointer initi...
An out-of-bounds heap buffer access issue was found in the ARM Generic Interrupt Controller emulator of QEMU up to and including qemu 4.2.0on aarch64 platform. The issue occurs because while writing an interrupt ID to the controller memory area, it is not masked to be 4 bits wide. It may lead to the said issue while updating controller state fields and their subsequent processing. A privileged guest user may use this flaw to crash the QEMU process on the host resulting in DoS scenario.