• J
    vhost_net: fix possible infinite loop · 35bff6e6
    Jason Wang 提交于
    mainline inclusion
    from mainline-5.2-rc2
    commit e2412c07
    category: bugfix
    bugzilla: 13690
    CVE: CVE-2019-3900
    
    -------------------------------------------------
    
    When the rx buffer is too small for a packet, we will discard the vq
    descriptor and retry it for the next packet:
    
    while ((sock_len = vhost_net_rx_peek_head_len(net, sock->sk,
    					      &busyloop_intr))) {
    ...
    	/* On overrun, truncate and discard */
    	if (unlikely(headcount > UIO_MAXIOV)) {
    		iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
    		err = sock->ops->recvmsg(sock, &msg,
    					 1, MSG_DONTWAIT | MSG_TRUNC);
    		pr_debug("Discarded rx packet: len %zd\n", sock_len);
    		continue;
    	}
    ...
    }
    
    This makes it possible to trigger a infinite while..continue loop
    through the co-opreation of two VMs like:
    
    1) Malicious VM1 allocate 1 byte rx buffer and try to slow down the
       vhost process as much as possible e.g using indirect descriptors or
       other.
    2) Malicious VM2 generate packets to VM1 as fast as possible
    
    Fixing this by checking against weight at the end of RX and TX
    loop. This also eliminate other similar cases when:
    
    - userspace is consuming the packets in the meanwhile
    - theoretical TOCTOU attack if guest moving avail index back and forth
      to hit the continue after vhost find guest just add new buffers
    
    This addresses CVE-2019-3900.
    
    Fixes: d8316f39 ("vhost: fix total length when packets are too short")
    Fixes: 3a4d5c94 ("vhost_net: a kernel-level virtio server")
    Signed-off-by: NJason Wang <jasowang@redhat.com>
    Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
    Conflicts:
     drivers/vhost/net.c
    [yyl: adjust context]
    Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: NZhen Lei <thunder.leizhen@huawei.com>
    Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
    35bff6e6
net.c 38.8 KB