oss-security - Re: CVE-2019-14835: QEMU-KVM Guest to Host Kernel Escape Vulnerability: vhost/vhost

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 3 Oct 2019 11:09:59 -0500
From: Tina Li <tli@...italocean.com>
To: oss-security@...ts.openwall.com, peterpi@...cent.com
Cc: Vineeth Remanan Pillai <vpillai@...italocean.com>
Subject: Re: CVE-2019-14835: QEMU-KVM Guest to Host Kernel Escape
 Vulnerability: vhost/vhost_net kernel buffer overflow

Hi Peter,

We are trying to follow your steps to reproduce the attack.

Our host is Ubuntu 18.04.2 LTS.

Guest is installed with Ubuntu 16.04.3 LTS, and we have built the
kernel with attached patches and install the built kernel.

Initially, we were using QEMU 4.1. After running  the echo command to
trigger the bug, the guest kernel crashes every time.

Here is the crash stack trace:

[  322.977160] kernel BUG at drivers/virtio/virtio_ring.c:685!

[  322.978252] invalid opcode: 0000 [#1] SMP PTI

[  322.979077] Modules linked in: kvm_intel kvm irqbypass input_leds
joydev serio_raw ib_iser mac_hid i2c_piix4 rdma_cm iw_cm ib_cm ib_core
configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4
btrfs zstd_decompress zstd_compress xxhash raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor
raid6_pq libcrc32c raid1 raid0 multipath linear qxl ttm drm_kms_helper
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc syscopyarea
sysfillrect sysimgblt fb_sys_fops drm aesni_intel pata_acpi aes_x86_64
crypto_simd glue_helper psmouse cryptd virtio_net virtio_scsi floppy

[  322.988821] CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 4.15.18+ #1

[  322.990012] Hardware name:

[  322.991303] RIP: 0010:detach_buf+0x104/0x110

[  322.992116] RSP: 0018:ffffaacd40ce7d50 EFLAGS: 00010246

[  322.993093] RAX: ffff8cda0e668000 RBX: ffff8cda0e4ec000 RCX: 0000000000000081

[  322.994411] RDX: 0000000000000000 RSI: ffff8cda0e668810 RDI: ffff8cda0ef9d400

[  322.995743] RBP: 0000000000000810 R08: 0000000000000000 R09: 0000000000000100

[  322.997068] R10: ffffaacd40ce7bf8 R11: 0000000000000000 R12: 0000000000000600

[  322.998391] R13: ffff8cda0e668810 R14: 0000000000000081 R15: ffff8cda0e4ec810

[  322.999712] FS:  0000000000000000(0000) GS:ffff8cda5fc80000(0000)
knlGS:0000000000000000

[  323.001225] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

[  323.002285] CR2: 0000000001f74208 CR3: 000000012120a004 CR4: 00000000007606e0

[  323.003598] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

[  323.004917] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

[  323.006236] PKRU: 55555554

[  323.006759] Call Trace:

[  323.007241]  virtqueue_get_buf_ctx+0x76/0x120

[  323.008058]  virtnet_poll+0x14a/0x300 [virtio_net]

[  323.008955]  ? tcp_delack_timer+0x6e/0xb0

[  323.009717]  net_rx_action+0x27e/0x3d0

[  323.010427]  __do_softirq+0xf8/0x29e

[  323.011125]  run_ksoftirqd+0x1e/0x40

[  323.011809]  smpboot_thread_fn+0x10e/0x160

[  323.012583]  kthread+0xf8/0x130

[  323.013181]  ? sort_range+0x20/0x20

[  323.013835]  ? kthread_destroy_worker+0x40/0x40

[  323.014681]  ret_from_fork+0x35/0x40

[  323.015364] Code: ff 49 c7 87 98 00 00 00 00 00 00 00 eb 10 4d 85
e4 74 0b 49 8b 87 98 00 00 00 49 89 04 24 5b 5d 41 5c 41 5d 41 5e 41
5f c3 0f 0b <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 47
38 55

[  323.018823] RIP: detach_buf+0x104/0x110 RSP: ffffaacd40ce7d50

[  323.019914] ---[ end trace 1f72aecb3b1ea4dc ]---

[  323.020819] Kernel panic - not syncing: Fatal exception in interrupt

[  323.022684] Kernel Offset: 0x3b000000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)

[  323.024639] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Setting _vq->indirect when *ctx is non-NULL might be leading to
BUG_ON() at a later point

=>

 684                 BUG_ON(!(vq->vring.desc[head].flags &

 685                          cpu_to_virtio16(vq->vq.vdev,
VRING_DESC_F_INDIRECT)));

Then we revert QEMU to 2.11.2, and re-do the test. In this scenario,
the guest kernel does not crash always, but we are unable to reproduce
the host crash during live migrate.

Please let us know if there is something missing in our test that is
causing the crash? Also, would be great if you could share more of
your environment details like Host OS/kernel, qemu version etc. Thanks
a lot!


Best regards,

Tianlin

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.