From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05C69C4320A for ; Mon, 30 Aug 2021 19:47:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D387660F5E for ; Mon, 30 Aug 2021 19:47:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234664AbhH3TsV (ORCPT ); Mon, 30 Aug 2021 15:48:21 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:22516 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234008AbhH3TsU (ORCPT ); Mon, 30 Aug 2021 15:48:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630352846; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7p/HFySufX7Ec/ARNQSZMmnEjbwiFtc+l8ArIs16Qfo=; b=SngN1sL0nidh1Tprgw5hqvzJZjZbHYLO7fYYInpfRFgGwu2sK/v+5LwOy0hMUM5r6zPJ8c 3grLxcwegtItbVi/rcIyB4bi6TL9qyPgAMI9kbWXe6sbQexzlygE2XQzD2rX3WxZMXKrxR aueuRo9mhRLHOzyihU6PYuxp5AV+R5M= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-273-eAy67iE3MxuG-Qtfa5Hlwg-1; Mon, 30 Aug 2021 15:47:24 -0400 X-MC-Unique: eAy67iE3MxuG-Qtfa5Hlwg-1 Received: by mail-lf1-f72.google.com with SMTP id q3-20020ac25283000000b003dedfdcf716so900673lfm.20 for ; Mon, 30 Aug 2021 12:47:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7p/HFySufX7Ec/ARNQSZMmnEjbwiFtc+l8ArIs16Qfo=; b=Ot1QLMEXy/KTQa2oQ2SvVfDsYB2YPyOHvHuJrWqCcySH8Xtzvj0qllAbOVycr9KcDG q8JuEshQXXiLCCJ7wf9g3OKvpNLPf4CTOArhhcdbuuVFy3PVtPoHnBsRiJTrUYE/8HCA xrcGF+xUb9hIqTFQUg1TWD0IBp1QCkuiziJEMehc9JfNr9hKqZMsfu8o/HX1cVGvmXNf HlVqqVHOhqpntUeIk/mb0q7J6F7byrKA67q0Gq/2/93SQ6SnQuD5ctskOAXibO8Z64Sh OapILUs0oFSi1kTLcwXa7vXB6Xc+6GhvUbjNfbyZ1j/hYWu3xov3G3Fdod8HcZ6ZuzYY OJig== X-Gm-Message-State: AOAM531ir7zRiEMjZNzq1GKwmys5PlfZ6kfe+IOz5JTc9X2UfzOHgegV E+jg8w5SwLF7eWCitkDDyaln49EZOwoAs95rwanmVtDc4zFHRfrFjiTG9QTemnmvsgq5su/hNdx s+X6MOWPnt00DKNbZgjD84AdUeVgB7wZ1+qso5kXQ X-Received: by 2002:a2e:90cf:: with SMTP id o15mr22292319ljg.14.1630352843040; Mon, 30 Aug 2021 12:47:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznUIXAUwxaYc1pT3l5/1NatkQ/kD+6GtozwDSBVoxs81xARSWQiNaDWMLcZ+Vo/mr5xhfBG0iSCSHFvF5EYbQ= X-Received: by 2002:a2e:90cf:: with SMTP id o15mr22292305ljg.14.1630352842833; Mon, 30 Aug 2021 12:47:22 -0700 (PDT) MIME-Version: 1.0 References: <20210823143028.649818-1-vkuznets@redhat.com> <20210823143028.649818-5-vkuznets@redhat.com> <20210823185841.ov7ejn2thwebcwqk@habkost.net> <87mtp7jowv.fsf@vitty.brq.redhat.com> <87k0kakip9.fsf@vitty.brq.redhat.com> <2df0b6d18115fb7f2701587b7937d8ddae38e36a.camel@redhat.com> In-Reply-To: <2df0b6d18115fb7f2701587b7937d8ddae38e36a.camel@redhat.com> From: Nitesh Lal Date: Mon, 30 Aug 2021 15:47:10 -0400 Message-ID: Subject: Re: [PATCH v2 4/4] KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect() To: Maxim Levitsky Cc: Vitaly Kuznetsov , Eduardo Habkost , kvm@vger.kernel.org, Paolo Bonzini , Sean Christopherson , Wanpeng Li , Jim Mattson , "Dr. David Alan Gilbert" , Nitesh Narayan Lal , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 24, 2021 at 12:08 PM Maxim Levitsky wrote: > > On Tue, 2021-08-24 at 16:42 +0200, Vitaly Kuznetsov wrote: > > Eduardo Habkost writes: > > > > > On Tue, Aug 24, 2021 at 3:13 AM Vitaly Kuznetsov wrote: > > > > Eduardo Habkost writes: > > > > > > > > > On Mon, Aug 23, 2021 at 04:30:28PM +0200, Vitaly Kuznetsov wrote: > > > > > > KASAN reports the following issue: > > > > > > > > > > > > BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm] > > > > > > Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798 > > > > > > > > > > > > CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- --- > > > > > > Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020 > > > > > > Call Trace: > > > > > > dump_stack+0xa5/0xe6 > > > > > > print_address_description.constprop.0+0x18/0x130 > > > > > > ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] > > > > > > __kasan_report.cold+0x7f/0x114 > > > > > > ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] > > > > > > kasan_report+0x38/0x50 > > > > > > kasan_check_range+0xf5/0x1d0 > > > > > > kvm_make_vcpus_request_mask+0x174/0x440 [kvm] > > > > > > kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm] > > > > > > ? kvm_arch_exit+0x110/0x110 [kvm] > > > > > > ? sched_clock+0x5/0x10 > > > > > > ioapic_write_indirect+0x59f/0x9e0 [kvm] > > > > > > ? static_obj+0xc0/0xc0 > > > > > > ? __lock_acquired+0x1d2/0x8c0 > > > > > > ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm] > > > > > > [...] > > > I also don't like that ioapic_write_indirect calls the kvm_bitmap_or_dest_vcpus twice, > and second time with 'old_dest_id' > > I am not 100% sure why old_dest_id/old_dest_mode are needed as I don't see anything in the > function changing them. > I think only the guest can change them, so maybe the code deals with the guest changing them > while the code is running from a different vcpu? > > The commit that introduced this code is 7ee30bc132c683d06a6d9e360e39e483e3990708 > Nitesh Narayan Lal, maybe you remember something about it? > Apologies for the delay in responding, I just got back from my PTO and still clearing my inbox. Since you have reviewed this patch the only open question is the above so I will try to answer that. Please let me know in case I missed anything. IIRC IOAPIC can be reconfigured while the previous interrupt is pending or still processing. In this situation, ioapic_handeld_vectors may go out of sync as it only records the recently passed configuration. Since with this commit, we stopped generating requests for all vCPUs we need this chunk of code to keep ioapic_handled_vectors in sync. Having said that perhaps there could be a better way of handling this (?). -- Thanks Nitesh