Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp964320iob; Fri, 13 May 2022 17:55:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzhdpCQHXLc6/NXwIAbZPNEqDbnnQV6v+cS52+fM/RVm3/vZcPDl4mebrLM44jnU89RmCBP X-Received: by 2002:a05:6000:1acd:b0:20c:811c:9f39 with SMTP id i13-20020a0560001acd00b0020c811c9f39mr5852431wry.482.1652489746218; Fri, 13 May 2022 17:55:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652489746; cv=none; d=google.com; s=arc-20160816; b=bTX1c802MVsaWVCeTQ/0nhi6GII4Ti9hEIPiSIYc4EKZe+nG4+USIF2bqs1Hqkm0bG ZuVzgt0nVYxYgHWFfAf/0NBk2E5AGzed6Gag/0pi7A80RolHNw26GGhWqAOUte+7BxCw rt5vZPGf/1C2ELhFSWcd29nmwgewjLt9VC2pWzOJHzE/LERJfH2avA41XNb6Q+9MeMxf o7BVQ5sMibjdeaRY5myCq//8bpcR64/YnW1aJmJAjXST/mJN3KL/GAQordrNytolU6lQ KhS3JlM3p5q3mGnrQk+0A2SAq1g2VFcp809mS9TIN4I7xpYyxxbCVyGd5LGtJ3VaXF7k xDqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=WNun4ZTStfT49QHEpCQD8tjXU6kqYy14sdjKYugygVM=; b=rPQjnqdPvwMBbq9H//QYvin1IbfxPnwpwYpBrkr+QwZGgNOJcA5ZBrFN1VpOq6y257 IdddRMehn8A0Q1TwezWnJJM2itrQJpAsRvny5gwnJGaCu1McwwT/VN9n2tt5QeHoxolh pvmpqwovw8KUuRd378+V+L68ErOeaF7izS1a88vTlK+ftOjhtahXddEHa/BUDTlN0v8N SqjPXVS/6jgsYc25eA0NG53pwyoIt7gNspN9N6aNVHzFr7rSyra9MA8nC3Emq43N/SEs EsCSwCBM+MQhKjIN47+c0AzPnF2KhkRcRiVvflYZxXILR1GJbBZ/InBsX8ulp4j3Lr4G wOPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=dugEPaRn; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id v19-20020a05600c215300b0038ed2f750edsi6211220wml.233.2022.05.13.17.55.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 17:55:46 -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=@google.com header.s=20210112 header.b=dugEPaRn; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 18160351C50; Fri, 13 May 2022 16:31:05 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1381350AbiEMNit (ORCPT + 99 others); Fri, 13 May 2022 09:38:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1381484AbiEMNha (ORCPT ); Fri, 13 May 2022 09:37:30 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 344DDE2E for ; Fri, 13 May 2022 06:37:28 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id f4so1741916lfu.12 for ; Fri, 13 May 2022 06:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WNun4ZTStfT49QHEpCQD8tjXU6kqYy14sdjKYugygVM=; b=dugEPaRnc81vdHcYLXTwEg09DwWdgNK8aq3YFDbhGqRHq2+0pH78YRR5OacHw/9ekI SeTPlA9FCZnmbjeCdFVit5DAKGDM/YLaXvR1mqygL2qq0vIMkmqele/NXQyAT8bVC1/W hZufPIDp9VFsZcy61dw0456Y5ekfWsyaZ4K6ceC+4QUWjppBEtfq+tKnCsxVxi6gJwtO sLqWW+iXN8gL7dTyfh7yGuEufpQ2/TRPytHGs9DeLfcvYGQ7/9lsLNau3G/o5kuJRumh iINyZNx+I/FJa9RFkQFP8AMhm3r5LhuRFcy0myq7BcvYDpaE7x48jAcm1ArDnJg/gRNC msmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WNun4ZTStfT49QHEpCQD8tjXU6kqYy14sdjKYugygVM=; b=p5iFwasyrpUHTJtJm+QuTthcXEJqk+mA6kudvzntD54e/iO1E7VsS6piNRUb5EMshv m1HvmDij0DPsikYn9KCkTawwRCl0SWEqhtfZlLuFqTg8tOZJVOB6zAb4CL52yKvxG7// QMuvXY3VN20kpOri0SJn6dfLij7aTLGfnMX1IRN4RL/twDh1Zq6APikpciC7C0bHevyu RH6PxlwzjrqhYj8oXOwSwN6D7Fw9Tay3NGhJTVfaGDsO1jV+lQ/Q0U0UGXnvkdeKLItA hVC5KWpetfqBAP2Pw4mATF7ztZ+d0lyxOAzkWyERruOpZt5RRL83yQ+UnaNtjTt6+LTH 7xQg== X-Gm-Message-State: AOAM5301HPkJZWnYSNnDP7H0dNj4GXgEAbaRz9CK+goK58UvATI1hAAg u0YR7EAqiodyuthwwfUMs9p/UOcvO2ABdzQ8WKahEw== X-Received: by 2002:a05:6512:234c:b0:473:c3ba:2cf1 with SMTP id p12-20020a056512234c00b00473c3ba2cf1mr3518251lfu.402.1652449046335; Fri, 13 May 2022 06:37:26 -0700 (PDT) MIME-Version: 1.0 References: <20220512202328.2453895-1-Ashish.Kalra@amd.com> In-Reply-To: <20220512202328.2453895-1-Ashish.Kalra@amd.com> From: Peter Gonda Date: Fri, 13 May 2022 09:37:15 -0400 Message-ID: Subject: Re: [PATCH] KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel memory leak. To: Ashish Kalra Cc: Paolo Bonzini , Sean Christopherson , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Joerg Roedel , "Lendacky, Thomas" , Borislav Petkov , "the arch/x86 maintainers" , kvm list , LKML , Andy Nguyen , David Rientjes , John Allen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no 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 On Thu, May 12, 2022 at 4:23 PM Ashish Kalra wrote: > > From: Ashish Kalra > > For some sev ioctl interfaces, the length parameter that is passed maybe > less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data > that PSP firmware returns. In this case, kmalloc will allocate memory > that is the size of the input rather than the size of the data. > Since PSP firmware doesn't fully overwrite the allocated buffer, these > sev ioctl interface may return uninitialized kernel slab memory. > > Reported-by: Andy Nguyen > Suggested-by: David Rientjes > Suggested-by: Peter Gonda > Cc: kvm@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Ashish Kalra > --- > arch/x86/kvm/svm/sev.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Can we just update all the kmalloc()s that buffers get given to the PSP? For instance doesn't sev_send_update_data() have an issue? Reading the PSP spec it seems like a user can call this ioctl with a large hdr_len and the PSP will only fill out what's actually required like in these fixed up cases? This is assuming the PSP is written to spec (and just the current version). I'd rather have all of these instances updated.