Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp2928386iob; Mon, 16 May 2022 09:11:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpm7VmoqnQ5h6+lgv+yCEJZInyM4p72US+ZVjX/k976N7CXvAjr//uy5agVllULHsQa8Ar X-Received: by 2002:a63:1050:0:b0:3c2:2f7c:cc78 with SMTP id 16-20020a631050000000b003c22f7ccc78mr16240341pgq.238.1652717482796; Mon, 16 May 2022 09:11:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652717482; cv=none; d=google.com; s=arc-20160816; b=K6IWIrgTU549Ms4Vo0MpvLqseR2k2GyVQhHjXAUiYx7qUYQBN/UehD0hgpR+UEFpdI MmEtRRITsV/V1Hau3AtTyqQxW5FTaMU3OKWixrLwCcBlGFWqDFDaW6QmMKmNKRVsb/o3 EGNHcySoMukoJlobT46QtvgiuY+cZstc+mEvhx79o+x5fPcsKQs8uBrAVYK8pAbzhTVB v++4TL7SlwnwO6WIHoavKURYRuDscAQFmeXd+5c0UTGUqZ9tGQACBW9BGgXEYOtlpGTp HGBBU4Za0SmhVWz789JgqdvcAqGKu99hsJr2FKFSZhf7PCqmiP+hfJ/TQ7aQfQQXxW9Z gR1A== 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=EbahZ8s//MhvZATU5N16vyp5s7VaSnO5nIae4gl0gk0=; b=t0WkYJrIUFJsv9Ib9MIBn1fdUmM/uChGkl10W8MKAAYy6Q3sQ7yA9ZDBCtjgzsupHV xrDWZ6TXu100mxham3rJKqZ+I9Rxb3vkjKDEB2TPmuYJ/RsnBQSq3yWwPwNHWXj/K6my z0NBkMpS2Nrg+5St0UjojTW1PEM10GJ0nlJCPrFCBEXij3I/YEUPHwDx0Y7MJGKYEcus Aav5JjCOlkzfg8Mm/a39KB1kTfx7/ZxGulO78e+zcRByAzCIwEgzjLyqcmY7qU7MBC6n wn3+xJOqYuqMeUnqb38JOj85iJGM1MEMlGzK3SDkkNMBA9lEZv/SZXe2hvK46vGAoCmM OhHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=ZP4hri7b; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p8-20020a056a000b4800b005104bd4abfbsi13655779pfo.22.2022.05.16.09.11.09; Mon, 16 May 2022 09:11:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=ZP4hri7b; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245461AbiEPPxh (ORCPT + 99 others); Mon, 16 May 2022 11:53:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245454AbiEPPxe (ORCPT ); Mon, 16 May 2022 11:53:34 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90931286E8 for ; Mon, 16 May 2022 08:53:29 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id h29so26634243lfj.2 for ; Mon, 16 May 2022 08:53:29 -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=EbahZ8s//MhvZATU5N16vyp5s7VaSnO5nIae4gl0gk0=; b=ZP4hri7brP1qH58wG7aKs9+/EslXVGswsHOgXd3Rly2rJt/+O76tPfhxL7OwmpIwKG 6wxQXWKip2N/EbSsEuz8ZCxYCRYXfvipes/E3nYbQNtQdToMtCFZTl+dbTP2aNk37M9M gkn5YyTaHT7izE374+uIt7ybmQc99y30uNZ+augubzOaQ7Hme6ZJ8C9uj5dwxNr6yOrv itifkK9fRB+fkvL/kQ47zp+yg5CvyBsRLWTxZrPn/3NM3P10rrFzAU7DsLksyzRXTWpQ Ze+X+dmzPJiFyVH2T14K1fYnM7qMHdH0cQuOcMtHoY6Rv+G6cu0e6ghaQJ5PT6NS9ayK 5C/g== 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=EbahZ8s//MhvZATU5N16vyp5s7VaSnO5nIae4gl0gk0=; b=QTzoCMxPEI0i5iLFFrjQlYn/55fmcAEMdWf3gLwO1j2l+EG0WzCzpzgbkZk34HUzA3 KFXZXodbKMddsGNPaMQMfG9mzJiml1C3Pg9AdeecVZjeTs/QUUqOtGAQzTX4A5RdAdz0 0KoM/L6I/fuuyrGgU4qI3fsJZ3cPe2Dwd+2zzsJC3ksK1QVkBW7FTs4xZIU/CBxIV3Y/ 4EWeACOVSjbj0OA0JsxCySvraXka9SIV1Q+EDCLJvGoluOglIpUkVEhUP5p4dFelbRol Sk7unZs5L4IU6Xhj83ovJE6pie/PzVcfEn3KFgD1KKCVdwpSeuqiNVQxS8qkaX7OF7OG /a5Q== X-Gm-Message-State: AOAM5307fOLt5lSEN7k8tFYIUxZCa2Qu5+pqzCIx3xRL38cVb5xWgys4 kp2x4HL5hHy6fYHwjwbZA75d9hWskf2fvQ1D+EgGB3wm/SNQDA== X-Received: by 2002:a05:6512:234c:b0:473:c3ba:2cf1 with SMTP id p12-20020a056512234c00b00473c3ba2cf1mr13694486lfu.402.1652716407646; Mon, 16 May 2022 08:53:27 -0700 (PDT) MIME-Version: 1.0 References: <20220516154512.259759-1-john.allen@amd.com> In-Reply-To: <20220516154512.259759-1-john.allen@amd.com> From: Peter Gonda Date: Mon, 16 May 2022 08:53:16 -0700 Message-ID: Subject: Re: [PATCH v2] crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak To: John Allen Cc: Herbert Xu , Linux Crypto Mailing List , Sean Christopherson , "Lendacky, Thomas" , Ashish Kalra , LKML , Andy Nguyen , David Rientjes , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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-crypto@vger.kernel.org On Mon, May 16, 2022 at 8:46 AM John Allen wrote: > > For some sev ioctl interfaces, input may be passed that is 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 buffer, the sev ioctl interfaces with the > issue may return uninitialized slab memory. > > Currently, all of the ioctl interfaces in the ccp driver are safe, but > to prevent future problems, change all ioctl interfaces that allocate > memory with kmalloc to use kzalloc. > > Fixes: e799035609e15 ("crypto: ccp: Implement SEV_PEK_CSR ioctl command") > Fixes: 76a2b524a4b1d ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command") > Fixes: d6112ea0cb344 ("crypto: ccp - introduce SEV_GET_ID2 command") > Cc: stable@vger.kernel.org > Reported-by: Andy Nguyen > Suggested-by: David Rientjes > Suggested-by: Peter Gonda > Signed-off-by: John Allen > --- > v2: > - Add fixes tags and CC stable@vger.kernel.org > --- static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp) { struct sev_user_data_status data; int ret; ret = __sev_do_cmd_locked(SEV_CMD_PLATFORM_STATUS, &data, &argp->error); if (ret) return ret; if (copy_to_user((void __user *)argp->data, &data, sizeof(data))) ret = -EFAULT; return ret; } Would it be safer to memset @data here to all zeros too?