Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3783355pxb; Tue, 17 Nov 2020 03:31:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJwjzNlMIrxOSnlkk9sePDFrLhEVVf7iXf7Jn5DSiFtCoZA8w62LEzOUxyiNNu5oZWpxf4pR X-Received: by 2002:a17:906:1e04:: with SMTP id g4mr19131238ejj.72.1605612690071; Tue, 17 Nov 2020 03:31:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605612690; cv=none; d=google.com; s=arc-20160816; b=Kxryg6KUambhkYqf2d0LMOQ8z0tNqgwO2/c9MxfihN/2AT0ahcaoH8do4z3dFRH1Nk xluIxuMkqr2zzeucryAvKLbDpoPtfIMdxTG5ldugo6Uw8gKp1P6eCMkI8aqVbX9vg8Z3 OiO1RJMCzgxeuCz+f72o5mTzn63rTeBI8/kA9A2b5vOMUm5EwOp8i0BT5W0iogcRsQVh SvEK2FGfR5MNjB7qaRW4fT8kki+/kdkVeGfnmf2EDPoLVDbHv6kp5S9WYBkh46/njorh B6ObQHpPd4tT+4S1zlS8/gmk2BM3sHb4SMFqQos9wodBOrW6Ac4RNif8aOwi5+DCxCWy a2ow== 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 :references:in-reply-to:date:cc:to:from:subject:message-id :ironport-sdr:ironport-sdr; bh=06/qudHpynWLhjWad2IJVsLJvpJNrZqD/DXG++DuMHg=; b=NPchkN3sgKJjnlfOf9llCvaIdQYQxOzgb0rwFaUmANFKeJ53D28HNZtjR77BnequQc A5EeK5Jp++gPEzD4jxnnsmw3ABY0GW2HgXI+szbtKc1akqVsMPOFTbITyxcubiZo/zYH 2Q32P9kw9Y7zeylQj1fEJxX91prJbEUKaDaYBjCgA3lUnAbIpLAg36rlaQ4IkFrUaeV6 6g9heJXOkzmDUkoM/larduK1FUUIr8BNi2Yi5/bxUw0efCKqZgKZi8ZBuluOhQlSpj4/ 4GHOGoSQ4aI5UX+w8b9L8UuhpEMi2H5gkB1NnGM9ySgPwbqQ+RSrRO1hcn5p8TOJL7RT Iw6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r17si13398040edv.234.2020.11.17.03.31.07; Tue, 17 Nov 2020 03:31:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728017AbgKQL1x (ORCPT + 99 others); Tue, 17 Nov 2020 06:27:53 -0500 Received: from mga01.intel.com ([192.55.52.88]:1082 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725355AbgKQL1x (ORCPT ); Tue, 17 Nov 2020 06:27:53 -0500 IronPort-SDR: 5cLWV8aVxJr1wx73M7yifHYrpfjBzwjJ0efANfihBlp4uG8uRr3Kwz4J4rLGPHwjvl2PuTl6ne P6SXBCAzxjww== X-IronPort-AV: E=McAfee;i="6000,8403,9807"; a="188961214" X-IronPort-AV: E=Sophos;i="5.77,485,1596524400"; d="scan'208";a="188961214" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Nov 2020 03:27:52 -0800 IronPort-SDR: dG1ny2XRRY/+PJJPjr68EMmoLNYp7HC3dGGtUVrmxGNxJadnv2NJr5ZmpnPZ5JCtnw3qcgPK+G 4sglLFud5/AA== X-IronPort-AV: E=Sophos;i="5.77,485,1596524400"; d="scan'208";a="544009964" Received: from lil6-mobl1.ccr.corp.intel.com ([10.255.30.220]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Nov 2020 03:27:50 -0800 Message-ID: Subject: Re: [PATCH] thermal: Fix NULL pointer dereference issue From: Zhang Rui To: Daniel Lezcano , Mukesh Ojha , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: amitk@kernel.org Date: Tue, 17 Nov 2020 19:27:47 +0800 In-Reply-To: References: <1605544181-5348-1-git-send-email-mojha@codeaurora.org> <4e28affd89ba8a852e0fb7ace076458b3d43839a.camel@intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-11-17 at 09:57 +0100, Daniel Lezcano wrote: > On 17/11/2020 08:18, Zhang Rui wrote: > > On Mon, 2020-11-16 at 21:59 +0530, Mukesh Ojha wrote: > > > Cooling stats variable inside > > > thermal_cooling_device_stats_update() > > > can get NULL. We should add a NULL check on stat inside for > > > sanity. > > > > > > Signed-off-by: Mukesh Ojha > > > --- > > > drivers/thermal/thermal_sysfs.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/thermal/thermal_sysfs.c > > > b/drivers/thermal/thermal_sysfs.c > > > index a6f371f..f52708f 100644 > > > --- a/drivers/thermal/thermal_sysfs.c > > > +++ b/drivers/thermal/thermal_sysfs.c > > > @@ -754,6 +754,9 @@ void > > > thermal_cooling_device_stats_update(struct > > > thermal_cooling_device *cdev, > > > { > > > struct cooling_dev_stats *stats = cdev->stats; > > > > > > + if (!stats) > > > + return; > > > + > > > > May I know in which case stats can be NULL? > > The only possibility I can see is that cdev->ops->get_max_state() > > fails > > in cooling_device_stats_setup(), right? > > A few lines below, the allocation could fail. > > stats = kzalloc(var, GFP_KERNEL); > if (!stats) > return; > > Some drivers define themselves as a cooling device state to let the > userspace to act on their power. The screen brightness is one example > with a cdev with 1024 states, the resulting stats table to be > allocated > is very big and the kzalloc is prone to fail. > Oh, right. As we're not going to fix the cdev, so I think we do need this patch, right? thanks, rui > > thanks, > > rui > > > > > spin_lock(&stats->lock); > > > > > > if (stats->state == new_state) > >