Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2118089ybl; Thu, 29 Aug 2019 03:55:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqzGFi5x6iTII+YZaRqgYzIJhMak/N2hl5QoDUsEeV9Mb9ofg3qnDd4iunviVrFqBKdmfJQx X-Received: by 2002:a63:24a:: with SMTP id 71mr7587173pgc.273.1567076136259; Thu, 29 Aug 2019 03:55:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567076136; cv=none; d=google.com; s=arc-20160816; b=tXH/L8hNwEd7xmFVTkUE0WwqFmBVK6rIvrI4X7nf4vwx4CbHCBZD801Nj+P/7uC8HT 5YkFnz/DOqtZCE1PuBixu5hW0ukR9cpjaNsicSxZU0x7pPEPTXouzob0/KSmf2ujaQY+ rJzySDhq0EhFSt8QAYRVovsCk3Sl5SyMEhX+YFn4vmUOrdDKZsZPJDN8NGrzDe3vukce 9gAUnKEyMUbAzuYvU8OJcjklCwofFQP6RIO6P6+svxZOR+rIx3MP8IFU91+fgJeRs1vT UNg/ogn3/gQ9TdEDSw1hpFOauM+AWxWTB2AV2u5gihqmePKHvX7o6BWvL/cxZs7hj3kE C8Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=naoaBl3QTnzwfXcdYUCVMItMFt43qtye5w4wm7HyZqY=; b=mE0PhAXzGdnwt76OUJl1E0Mq5Gnj5baVYE6FC41AHHE7vk9eP2VHErdaEhTNyACevT YMkic2iTom3nsgnvWrWGayK1j4t4MQqhh2HjB+PRzW92Dybdk11lv49se9zjNByFe1Ij xjSF8r3D14qGYYORJO1/DmrzZd93GxEwS+c7Zpr0G9BudgW58SsLepsB7IiYJiE0SJgV ukOoMpNYqBxykvXzEQXAXHipccJpvqWSytFDhqIZICRwHM+UA3QRCq6a7Q5Ajqu2RFyX wAS0bahxrBKcFJfMUuDzfd8Io6yQMXdP+9w/9MA2PTgAEGxLlYbzNtM4XBcRmrHTWMxU LrwQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n9si1668823pgq.240.2019.08.29.03.55.21; Thu, 29 Aug 2019 03:55:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728742AbfH2KyH (ORCPT + 99 others); Thu, 29 Aug 2019 06:54:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3732 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727075AbfH2KyG (ORCPT ); Thu, 29 Aug 2019 06:54:06 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BE03C3C93E; Thu, 29 Aug 2019 10:54:05 +0000 (UTC) Received: from thuth.com (ovpn-116-53.ams2.redhat.com [10.36.116.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id 676CD5C1D6; Thu, 29 Aug 2019 10:54:00 +0000 (UTC) From: Thomas Huth To: Christian Borntraeger , Janosch Frank , kvm@vger.kernel.org Cc: David Hildenbrand , Cornelia Huck , Heiko Carstens , Vasily Gorbik , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] KVM: s390: Test for bad access register at the start of S390_MEM_OP Date: Thu, 29 Aug 2019 12:53:56 +0200 Message-Id: <20190829105356.27805-1-thuth@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 29 Aug 2019 10:54:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If the KVM_S390_MEM_OP ioctl is called with an access register >= 16, then there is certainly a bug in the calling userspace application. We check for wrong access registers, but only if the vCPU was already in the access register mode before (i.e. the SIE block has recorded it). The check is also buried somewhere deep in the calling chain (in the function ar_translation()), so this is somewhat hard to find. It's better to always report an error to the userspace in case this field is set wrong, and it's safer in the KVM code if we block wrong values here early instead of relying on a check somewhere deep down the calling chain, so let's add another check to kvm_s390_guest_mem_op() directly. Signed-off-by: Thomas Huth --- arch/s390/kvm/kvm-s390.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index f329dcb3f44c..725690853cbd 100644 --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -4255,7 +4255,7 @@ static long kvm_s390_guest_mem_op(struct kvm_vcpu *vcpu, const u64 supported_flags = KVM_S390_MEMOP_F_INJECT_EXCEPTION | KVM_S390_MEMOP_F_CHECK_ONLY; - if (mop->flags & ~supported_flags) + if (mop->flags & ~supported_flags || mop->ar >= NUM_ACRS) return -EINVAL; if (mop->size > MEM_OP_MAX_SIZE) -- 2.18.1