Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4500602ybb; Tue, 7 Apr 2020 08:40:21 -0700 (PDT) X-Google-Smtp-Source: APiQypJmYDTW3qh86zQAdWTnZVaUtJLBuCFfAq2IYd2AErhzXg0vcBqf/B4E4dXA09KfCX9NaXLn X-Received: by 2002:a9d:5191:: with SMTP id y17mr2144052otg.267.1586274021639; Tue, 07 Apr 2020 08:40:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586274021; cv=none; d=google.com; s=arc-20160816; b=JPKV/NdQrnbl3jkhRpImeZ6jbTLGKQHQvAP7ervCgP7ut+TJXBAFK7fBit+H4AnVLj THq4jE0mkOhuSL2GBR9NeHKb1gJFwRIg8BYrxi6NiSaAXFbPzuBkqI6yQYN7gZwsTCEU 5yxuoHrKcCyogTcV9nfk5oqfahP/RadiURM8NAu9KTiiYjXOgGIz2LTyztItLJw/Ryjc 1ye7DoUbZy56C6WfPVYTkTr2RhbYePnLglBUYW1bE5fcSyBtvDBsT+vpPIICiUZHMNSN Bb4rK8iHCLDm8VSs/0naNBkKSuNdxokOQTuxPz0X+984EQiOcmJUJNSEPts3jwY30igN Vrwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :dlp-reaction:dlp-version:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:ironport-sdr:ironport-sdr; bh=EaCn6XV+BpOoYnjSFoxz7/8xrdTnI12bbtCoQLfSGQc=; b=qKoB8Zpzccblwx4TBBTdXenOeHgYg8P2uoElJv5rX23O6oW5RlPqsS3WX6dhDCd9ri xxoh4M/iikAmR83UjL0fZC0XztFx8Deh4+bykm1KhpEtH+9Cp5nVhmQmWGDoAQ7pVHoy cs4cq6UjJXAhVSI/5SnFzQBxYobx8thLBHXHsDtA0HU0IbpRHqkPu9lgPbV214rf3WPB QatsCzDE7gizvCGaQnC4xBM0VulgUhwU9zbvxTQLBNJMM4etJgK3EIPqWrnxsL+0dXBs zN8BMpfgt6EyShca2BR7hskz2dF0HGu/2mCmqYKyQon9/wTzF5G92eqHRfyKF5lHaT+b YnvQ== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w29si1522693oth.24.2020.04.07.08.40.09; Tue, 07 Apr 2020 08:40:21 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729499AbgDGPiE convert rfc822-to-8bit (ORCPT + 99 others); Tue, 7 Apr 2020 11:38:04 -0400 Received: from mga17.intel.com ([192.55.52.151]:64829 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729487AbgDGPiD (ORCPT ); Tue, 7 Apr 2020 11:38:03 -0400 IronPort-SDR: Wzk3dd8w1VO3MI4jZ3gTSiKkOkkLAKTpdTlzEkiCehnhiKiQIccuAe++3W8zqwkxEJ8W0IzlA4 UDWoCoVNGw5Q== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2020 08:38:02 -0700 IronPort-SDR: bXareJ8KX03WGquwwUGGDoPz+2OZVOyeGzJRD2cw+of13iCL8L3F/ssAFo5gmAl2YBIYEYjiRD nlKO+rJXB+TQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,355,1580803200"; d="scan'208";a="296977211" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by FMSMGA003.fm.intel.com with ESMTP; 07 Apr 2020 08:38:02 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 7 Apr 2020 08:38:01 -0700 Received: from shsmsx108.ccr.corp.intel.com ([169.254.8.7]) by shsmsx102.ccr.corp.intel.com ([169.254.2.138]) with mapi id 14.03.0439.000; Tue, 7 Apr 2020 23:37:59 +0800 From: "Zhang, Rui" To: "Zhang, Rui" , Takashi Iwai , "Amit Kucheria" CC: Daniel Lezcano , Linux PM list , LKML Subject: RE: [PATCH] thermal: Add a sanity check for invalid state at stats update Thread-Topic: [PATCH] thermal: Add a sanity check for invalid state at stats update Thread-Index: AQHWBpzH0NNV6tuj6kqI2uO2gMago6htLiyAgAALuQCAAIctYIAAFoGA Date: Tue, 7 Apr 2020 15:37:58 +0000 Message-ID: <744357E9AAD1214791ACBA4B0B90926377CEDF78@SHSMSX108.ccr.corp.intel.com> References: <20200330140859.12535-1-tiwai@suse.de> <744357E9AAD1214791ACBA4B0B90926377CEDF41@SHSMSX108.ccr.corp.intel.com> In-Reply-To: <744357E9AAD1214791ACBA4B0B90926377CEDF41@SHSMSX108.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Too late for me to post it out by this midnight, will post it out tomorrow. Thanks, rui -----Original Message----- From: linux-pm-owner@vger.kernel.org On Behalf Of Zhang, Rui Sent: Tuesday, April 07, 2020 10:17 PM To: Takashi Iwai ; Amit Kucheria Cc: Daniel Lezcano ; Linux PM list ; LKML Subject: RE: [PATCH] thermal: Add a sanity check for invalid state at stats update Right, I have a V2 patch series, which will be post soon. Thanks, rui -----Original Message----- From: linux-pm-owner@vger.kernel.org On Behalf Of Takashi Iwai Sent: Tuesday, April 07, 2020 10:13 PM To: Amit Kucheria Cc: Takashi Iwai ; Zhang, Rui ; Daniel Lezcano ; Linux PM list ; LKML Subject: Re: [PATCH] thermal: Add a sanity check for invalid state at stats update Importance: High On Tue, 07 Apr 2020 15:30:51 +0200, Amit Kucheria wrote: > > On Mon, Mar 30, 2020 at 7:39 PM Takashi Iwai wrote: > > > > The thermal sysfs handler keeps the statistics table with the fixed > > size that was determined from the initial max_states() call, and the > > table entry is updated at each sysfs cur_state write call. And, > > when the driver's set_cur_state() ops accepts the value given from > > user-space, the thermal sysfs core blindly applies it to the > > statistics table entry, which may overflow and cause an Oops. > > Although it's rather a bug in the driver's ops implementations, we > > shouldn't crash but rather give a proper warning instead. > > > > This patch adds a sanity check for avoiding such an OOB access and > > warns with a stack trace to show the suspicious device in question. > > Hi Takashi, > > Instead of this warning, I think we should reject such input when > writing to cur_state. > > See attached patch. If you think this OK, I'll submit it. Actually the input value itself is correct, the problem is rather about the max_states that may vary depending on other driver. So IMO, we don't want to refuse the input completely. Please see the thread: https://lore.kernel.org/linux-acpi/s5h5zeiwd01.wl-tiwai@suse.de/ thanks, Takashi > > Regards, > Amit > > > Signed-off-by: Takashi Iwai > > --- > > > > We've hit some crash by stress tests, and this patch at least works > > around the crash itself. While the actual bug fix of the buggy > > driver is still being investigated, I submit the hardening in the > > core side at first. > > > > drivers/thermal/thermal_sysfs.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/thermal/thermal_sysfs.c > > b/drivers/thermal/thermal_sysfs.c index aa99edb4dff7..a23c4e701d63 > > 100644 > > --- a/drivers/thermal/thermal_sysfs.c > > +++ b/drivers/thermal/thermal_sysfs.c > > @@ -772,6 +772,11 @@ void thermal_cooling_device_stats_update(struct > > thermal_cooling_device *cdev, > > > > spin_lock(&stats->lock); > > > > + if (dev_WARN_ONCE(&cdev->device, new_state >= stats->max_states, > > + "new state %ld exceeds max_state %ld", > > + new_state, stats->max_states)) > > + goto unlock; > > + > > if (stats->state == new_state) > > goto unlock; > > > > -- > > 2.16.4 > > > From 54266260d483ab4476510dd4461a1cafc611e17d Mon Sep 17 00:00:00 2001 > Message-Id: > <54266260d483ab4476510dd4461a1cafc611e17d.1586266224.git.amit.kucheria > @linaro.org> > From: Amit Kucheria > Date: Tue, 7 Apr 2020 18:48:14 +0530 > Subject: [PATCH] thermal: Reject invalid cur_state input from > userspace > > We don't check if the cur_state value input in sysfs is greater than > the maximum cooling state that the cooling device supports. This can > cause access to unallocated memory in case THERMAL_STATISTICS in > enabled and could also crash cooling devices that don't check for an > invalid state in their set_cur_state() callback. > > Return an error if the state being requested in greater than the > maximum cooling state the device supports. > > Reported-by: Takashi Iwai > Signed-off-by: Amit Kucheria > --- > drivers/thermal/thermal_sysfs.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/thermal/thermal_sysfs.c > b/drivers/thermal/thermal_sysfs.c index 7e1d11bdd258..8033e5a9386a > 100644 > --- a/drivers/thermal/thermal_sysfs.c > +++ b/drivers/thermal/thermal_sysfs.c > @@ -703,7 +703,7 @@ cur_state_store(struct device *dev, struct device_attribute *attr, > const char *buf, size_t count) > { > struct thermal_cooling_device *cdev = to_cooling_device(dev); > - unsigned long state; > + unsigned long state, max_state; > int result; > > if (sscanf(buf, "%ld\n", &state) != 1) @@ -712,6 +712,13 @@ > cur_state_store(struct device *dev, struct device_attribute *attr, > if ((long)state < 0) > return -EINVAL; > > + result = cdev->ops->get_max_state(cdev, &max_state); > + if (result) > + return result; > + > + if (state >= max_state) > + return -EINVAL; > + > mutex_lock(&cdev->lock); > > result = cdev->ops->set_cur_state(cdev, state); > -- > 2.20.1 >