Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2383440ybi; Sun, 9 Jun 2019 10:21:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqzpglmnoPqPVR2cQNk62OzH4o1jLT+9cm/uw80LK+bd1GyBiM5qExY+DfhLmK8QWiGN3Znf X-Received: by 2002:a17:902:7297:: with SMTP id d23mr52860567pll.254.1560100910026; Sun, 09 Jun 2019 10:21:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560100910; cv=none; d=google.com; s=arc-20160816; b=MFZ58pDg7O8EZz4E4urKKLhuWtio0WmQn4QbD/66TpFCYcxkQbxMvdi5uY1AYcE051 awilgFOZo0WjJwp/nnLbIKnaiFN+2pL766YQ7w4r7pABB+sSUzXnA2cLflRg6z6g+zPO 9pte+5QN/6kvUeO9+UTKeOuIr5P6GL0McXRkDX7Nr4qVV478rWIlXK3gqDqVc1HVNJZs pPlm3YhyiozDiA2L8GnwavbIkG2SajMRqL2Sg4kjLpK9Q2CN1a520qgQoowgJAlQJwm0 MWbp8m5l/im96iDpZp9EyTbqKxZ7HNtd+hFuRz0+t/4AYOPsyHBD07BAfB9GiEv0OePq l0jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=NKLFZHcizMpxvA05UtNViCEXjZ3xrJk5dZa6xlIgD58=; b=dswH0WjmZJUZpoOl7CUt62c1uN+WfbN5iL0LH49pHT8UL0iQW6eb1lSQDL6a38bzef qZiba5sqj0kL/v8Jmm/ZpltVYJP99pksgBrtleIN3wWyZTpBW7o/Jjmku52TQxp62nZW i9JcxjR/J0+r7KasbaqmlVuOQ6V+lePPYTWoYuhjqt/pCTiLJb6evxx8N5uDcJA2bBGv s8sDewb9BxkX/irf6ejyy7TTnHpyIXOtR9KeJmoE8EjGTT1tsjNC40irDWjeyCV4JlB1 xelBSGN8OJ23L8KdZWD5+Fu5UJuNCl2jxznXSB33ZdDJMgeVANYpcsqU6t1uVYycyhzW 6wqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="RqRV/sE5"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f16si4286030pjg.50.2019.06.09.10.21.34; Sun, 09 Jun 2019 10:21:50 -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; dkim=pass header.i=@kernel.org header.s=default header.b="RqRV/sE5"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731139AbfFIQsO (ORCPT + 99 others); Sun, 9 Jun 2019 12:48:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:47200 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731122AbfFIQsM (ORCPT ); Sun, 9 Jun 2019 12:48:12 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8305D206C3; Sun, 9 Jun 2019 16:48:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560098892; bh=QjKTBDFXtqzZ+YF044l7hB5jMgsETESIngSJvWGBCc4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RqRV/sE5SUfkWpmRm4J4q3P8Cd62igic20XsJW1/h0pZpbtvJZ1dtcOiCqHCKnC5B A8bDVTxNErXeB/WZ6Zl5I0XMJo8Wlwkx2O4QkMff8f93YsaUu1GemZnWAfiKUIyjkU JEN+cS7avcpgZaRbjWssPx0oGwQ6Akr4icD0J8X4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kees Cook , Yaro Slav Subject: [PATCH 4.19 26/51] pstore/ram: Run without kernel crash dump region Date: Sun, 9 Jun 2019 18:42:07 +0200 Message-Id: <20190609164128.663731310@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190609164127.123076536@linuxfoundation.org> References: <20190609164127.123076536@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Kees Cook commit 8880fa32c557600f5f624084152668ed3c2ea51e upstream. The ram pstore backend has always had the crash dumper frontend enabled unconditionally. However, it was possible to effectively disable it by setting a record_size=0. All the machinery would run (storing dumps to the temporary crash buffer), but 0 bytes would ultimately get stored due to there being no przs allocated for dumps. Commit 89d328f637b9 ("pstore/ram: Correctly calculate usable PRZ bytes"), however, assumed that there would always be at least one allocated dprz for calculating the size of the temporary crash buffer. This was, of course, not the case when record_size=0, and would lead to a NULL deref trying to find the dprz buffer size: BUG: unable to handle kernel NULL pointer dereference at (null) ... IP: ramoops_probe+0x285/0x37e (fs/pstore/ram.c:808) cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size; Instead, we need to only enable the frontends based on the success of the prz initialization and only take the needed actions when those zones are available. (This also fixes a possible error in detecting if the ftrace frontend should be enabled.) Reported-and-tested-by: Yaro Slav Fixes: 89d328f637b9 ("pstore/ram: Correctly calculate usable PRZ bytes") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman --- fs/pstore/platform.c | 3 ++- fs/pstore/ram.c | 36 +++++++++++++++++++++++------------- 2 files changed, 25 insertions(+), 14 deletions(-) --- a/fs/pstore/platform.c +++ b/fs/pstore/platform.c @@ -583,7 +583,8 @@ int pstore_register(struct pstore_info * return -EINVAL; } - allocate_buf_for_compression(); + if (psi->flags & PSTORE_FLAGS_DMESG) + allocate_buf_for_compression(); if (pstore_is_mounted()) pstore_get_records(0); --- a/fs/pstore/ram.c +++ b/fs/pstore/ram.c @@ -803,26 +803,36 @@ static int ramoops_probe(struct platform cxt->pstore.data = cxt; /* - * Since bufsize is only used for dmesg crash dumps, it - * must match the size of the dprz record (after PRZ header - * and ECC bytes have been accounted for). + * Prepare frontend flags based on which areas are initialized. + * For ramoops_init_przs() cases, the "max count" variable tells + * if there are regions present. For ramoops_init_prz() cases, + * the single region size is how to check. */ - cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size; - cxt->pstore.buf = kzalloc(cxt->pstore.bufsize, GFP_KERNEL); - if (!cxt->pstore.buf) { - pr_err("cannot allocate pstore crash dump buffer\n"); - err = -ENOMEM; - goto fail_clear; - } - - cxt->pstore.flags = PSTORE_FLAGS_DMESG; + cxt->pstore.flags = 0; + if (cxt->max_dump_cnt) + cxt->pstore.flags |= PSTORE_FLAGS_DMESG; if (cxt->console_size) cxt->pstore.flags |= PSTORE_FLAGS_CONSOLE; - if (cxt->ftrace_size) + if (cxt->max_ftrace_cnt) cxt->pstore.flags |= PSTORE_FLAGS_FTRACE; if (cxt->pmsg_size) cxt->pstore.flags |= PSTORE_FLAGS_PMSG; + /* + * Since bufsize is only used for dmesg crash dumps, it + * must match the size of the dprz record (after PRZ header + * and ECC bytes have been accounted for). + */ + if (cxt->pstore.flags & PSTORE_FLAGS_DMESG) { + cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size; + cxt->pstore.buf = kzalloc(cxt->pstore.bufsize, GFP_KERNEL); + if (!cxt->pstore.buf) { + pr_err("cannot allocate pstore crash dump buffer\n"); + err = -ENOMEM; + goto fail_clear; + } + } + err = pstore_register(&cxt->pstore); if (err) { pr_err("registering with pstore failed\n");