Received: by 2002:ac2:464d:0:0:0:0:0 with SMTP id s13csp3675550lfo; Mon, 23 May 2022 11:05:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwH1c0BFRY6bsGG3J2ZodHb3ZDUsUZaBLkNv1nF8S1dSWi+tKrqzDeR607BrryEUCi5r9A7 X-Received: by 2002:a17:902:eb82:b0:161:f4c5:ec2 with SMTP id q2-20020a170902eb8200b00161f4c50ec2mr16826011plg.8.1653329117263; Mon, 23 May 2022 11:05:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653329117; cv=none; d=google.com; s=arc-20160816; b=wrJkDJcFDfleyyyljfUs5yYG/dIh22ICJAIgwLLgrssQJ5vmsSxg97P6E2rL3Or0Hx cIpBfF0WGQRA2yOAwVl8hUOrMh9Ci2ORcUDBKKIAqQ0fwHmEFbP07TRnclDTElQQFwQY lJy/2O7B0jMI1C6oGewvn9uFZ+81vChAtSHrdjWtGXUdU776qv3kzNzK14Ky19ZhB7R9 XNNE0ZxqXGb/sGG/gxWO7+n1lF6XiGb7VvEVWomTIAoQWHQpD9PKljsE4Xi0+9FDokzU +C1AiwK8Y5+yxswmxTehq8ep1IaPRt9TOM7CgOb7VT1K80a3nASvkml+cuwOOHwIOkEK CqCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=AQ46FUcO/h2ITm47oGmOJG+R7cnhR8S0OeLsie5+q8c=; b=FAd7vWA4e+CtlOg1KqOE7xq2PNtILd5+qK6NOHCuX0vy0xnq2Itp9uK9GBocw+lS9+ F9Q4ATLx2Wet6dha+rtDln6/ResWtJg/IztkCit4/pMpgC+hFFjmxbbLqh6S9mZR+wHY A3fd/kL4N6iAlMWn/zUr2fPP/855L//rFP0cNqGtS9P7OzicVPqMjMGXesnhDnMpmmKi t6Alyno3idHB2fNss71f6ir0WOBzJN5NHeSPUx0BP5NxuuFzXkOBmAwgWvo0Mdw7jCYL /r4rG5q8y/TJBrPtuJyGeMOqZG+BNpFvM/S+MbDJQ/BTe8vviDFkkA+SuIhHRaMSYCMS 5jsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=pYcx4agv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id 16-20020a056a00073000b0051842cffa45si13230947pfm.356.2022.05.23.11.05.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 11:05:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=pYcx4agv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DF8061EED5; Mon, 23 May 2022 11:01:15 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242800AbiEWRz5 (ORCPT + 99 others); Mon, 23 May 2022 13:55:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241445AbiEWRau (ORCPT ); Mon, 23 May 2022 13:30:50 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E891960D9D; Mon, 23 May 2022 10:26:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 25A9EB81218; Mon, 23 May 2022 17:26:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7FE86C385A9; Mon, 23 May 2022 17:26:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1653326783; bh=bfoCqacksBvKVXB6toCt+XCrQuXm+1nXdkvk2XHfhG8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pYcx4agvR8ivdDoWrNjIEvIj7FS0ErLt8RJ+cOgBIFOhEjewdOQ73tMeZjAFd6lyT hqH3ON/wH/Zga1V6xGw0oNUNvLY7AhDqFEBx25aDvBlIOyWkxY5vrnhc5WuNGhwA31 U9zZLFAqUQ6wquN5t9GqlTcFYR+xlJXlGz6oiKTQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+8606b8a9cc97a63f1c87@syzkaller.appspotmail.com, Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.17 057/158] KVM: Free new dirty bitmap if creating a new memslot fails Date: Mon, 23 May 2022 19:03:34 +0200 Message-Id: <20220523165840.249161905@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220523165830.581652127@linuxfoundation.org> References: <20220523165830.581652127@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sean Christopherson commit c87661f855c3f2023e40ddc364002601ee234367 upstream. Fix a goof in kvm_prepare_memory_region() where KVM fails to free the new memslot's dirty bitmap during a CREATE action if kvm_arch_prepare_memory_region() fails. The logic is supposed to detect if the bitmap was allocated and thus needs to be freed, versus if the bitmap was inherited from the old memslot and thus needs to be kept. If there is no old memslot, then obviously the bitmap can't have been inherited The bug was exposed by commit 86931ff7207b ("KVM: x86/mmu: Do not create SPTEs for GFNs that exceed host.MAXPHYADDR"), which made it trivally easy for syzkaller to trigger failure during kvm_arch_prepare_memory_region(), but the bug can be hit other ways too, e.g. due to -ENOMEM when allocating x86's memslot metadata. The backtrace from kmemleak: __vmalloc_node_range+0xb40/0xbd0 mm/vmalloc.c:3195 __vmalloc_node mm/vmalloc.c:3232 [inline] __vmalloc+0x49/0x50 mm/vmalloc.c:3246 __vmalloc_array mm/util.c:671 [inline] __vcalloc+0x49/0x70 mm/util.c:694 kvm_alloc_dirty_bitmap virt/kvm/kvm_main.c:1319 kvm_prepare_memory_region virt/kvm/kvm_main.c:1551 kvm_set_memslot+0x1bd/0x690 virt/kvm/kvm_main.c:1782 __kvm_set_memory_region+0x689/0x750 virt/kvm/kvm_main.c:1949 kvm_set_memory_region virt/kvm/kvm_main.c:1962 kvm_vm_ioctl_set_memory_region virt/kvm/kvm_main.c:1974 kvm_vm_ioctl+0x377/0x13a0 virt/kvm/kvm_main.c:4528 vfs_ioctl fs/ioctl.c:51 __do_sys_ioctl fs/ioctl.c:870 __se_sys_ioctl fs/ioctl.c:856 __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae And the relevant sequence of KVM events: ioctl(3, KVM_CREATE_VM, 0) = 4 ioctl(4, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=KVM_MEM_LOG_DIRTY_PAGES, guest_phys_addr=0x10000000000000, memory_size=4096, userspace_addr=0x20fe8000} ) = -1 EINVAL (Invalid argument) Fixes: 244893fa2859 ("KVM: Dynamically allocate "new" memslots from the get-go") Cc: stable@vger.kernel.org Reported-by: syzbot+8606b8a9cc97a63f1c87@syzkaller.appspotmail.com Signed-off-by: Sean Christopherson Message-Id: <20220518003842.1341782-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman --- virt/kvm/kvm_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1539,7 +1539,7 @@ static int kvm_prepare_memory_region(str r = kvm_arch_prepare_memory_region(kvm, old, new, change); /* Free the bitmap on failure if it was allocated above. */ - if (r && new && new->dirty_bitmap && old && !old->dirty_bitmap) + if (r && new && new->dirty_bitmap && (!old || !old->dirty_bitmap)) kvm_destroy_dirty_bitmap(new); return r;