Message ID | 20230723-thermal-fix-of-memory-corruption-v1-1-ed4fa16d199d@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9010:0:b0:3e4:2afc:c1 with SMTP id l16csp1025803vqg; Sat, 22 Jul 2023 16:54:57 -0700 (PDT) X-Google-Smtp-Source: APBJJlECY82Jpd3CWVNIGptDwDJpANSYFVDix7C3kGa/enpoyrfFSQWnFhsHRMJqtqV8yu228db6 X-Received: by 2002:aa7:d5cb:0:b0:521:a99b:a233 with SMTP id d11-20020aa7d5cb000000b00521a99ba233mr4870276eds.10.1690070097522; Sat, 22 Jul 2023 16:54:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690070097; cv=none; d=google.com; s=arc-20160816; b=g9pcf7UAKokfB5trsPWnPYXSwhY/KZS29OYbhiiOVNjiarTeOgohS8BLxM+7CojCk9 nK5LT/kALC0ofAHLLhXjoCfZ4R8k+SCBIbvfSFmivPrEPVCUa4GB70fxdgMjYHBpEYSi BrU75bpsHbp6idDDc9XDLiMsiW4C8ivov4+N3qZK4zDjDyyOblWsaWYElL5l7VdTEJST GxzxXdaXwH5VUv2t0bVuNSwhvezRQvqlGJYYtpC669JpvsPB3OEnw/rb//9toOAowGae JgNO/uCWHYV7ATQUPfL876jdLJ0YJiEUM4Up03n/6k3JJDBLnULHbQlwE+7w9UsykKFj FoEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=4FU3nLcM0QFvfuN2QbFyweJR49F3tFYXVr4pmwZvUSs=; fh=YkXM4MZTn8GelkFVU5cmCnQHiiVNqQ0Y929Fa4EXR38=; b=PqseDz3Lr2UrZ4P9vqOHCIHOdMFAsVQgO5EbE457aaxlXyGS2Wg24s9GtZ4v3eXoV2 NuJT2OiwQNcBEAvHTX5CgP+wO8+PyvJsnG5asSGOgYkZRuW3L406rPvrrmx4HKWwGwwZ 9IEoFA0LIf/KJupb50k5kmRvv5mCtTTFDuLtW1fiq+TKOON2gRUXN2MUeAQ7XOKDEHX3 WDWBdmJWOfsa/NqVCgpDE7SGsZM4LEGeBSbbTlwJxWtONcP1FNm1Mf8HoOza6LIpi+ha 6uqu937Iuj4tX4dy46mnCWhvW8WdrfozdjkD5pCuRd1NcSt0uUDMXpSdI8zLOy/WKXqf llWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=fumBeebR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n16-20020aa7db50000000b00522203d6448si665659edt.163.2023.07.22.16.54.34; Sat, 22 Jul 2023 16:54:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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=@kernel.org header.s=k20201202 header.b=fumBeebR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229711AbjGVX11 (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Sat, 22 Jul 2023 19:27:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229625AbjGVX10 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 22 Jul 2023 19:27:26 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E9A819A6; Sat, 22 Jul 2023 16:27:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9B67A60BD8; Sat, 22 Jul 2023 23:27:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88B7FC433C8; Sat, 22 Jul 2023 23:27:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690068443; bh=C5VTDtOqdmj6Bz6JgxfHCEKJHYyIn7v2H/pyJ1qHGCM=; h=From:Date:Subject:To:Cc:From; b=fumBeebR/fj9xdn8EzaaqJ9QKok8wxdstGCw6EiJin3k5PiQAkG2KkNz6Gz1Ds0LN GDotCebW5AX3X2f+BFcvxqW1q1McAvTRUDK93mXtfZEIrLVfebrXeHyyjEb1ZyLFNv uyYNrjOx1HH8Tpx1X62ur6o/H9HLwIVllLVbCd1EsZTQ6KrV09RJGrn38NucQtDdgn 5mdHBKFRU9R1009c0gEAMfbpcl0aQ+t7hhD1xcygkiiaAXMoP5zAnSR5rNtXKGFgKN sWyuVPCRaJEvsu1UFB2vMYHFZIUDhb+AbpATIjlhnP429Ec8yeecDHpZcGQaDdrVNh cp/5igG+AETrA== From: Mark Brown <broonie@kernel.org> Date: Sun, 23 Jul 2023 00:26:54 +0100 Subject: [PATCH] thermal/of: Fix double free of params during unregistration MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230723-thermal-fix-of-memory-corruption-v1-1-ed4fa16d199d@kernel.org> X-B4-Tracking: v=1; b=H4sIAL1lvGQC/x2N0QqDMAxFf0XybKBG0LFfGT64mtrAaiV1YyL+u 8HHA+eee0BhFS7wrA5Q/kmRvBg0dQU+jsvMKJMxkKPW9US4RdY0fjDIH3PAxCnrjj6rftfNxti 33tzw6Bp6g2VWZXPvi9dwnheUwZCCcgAAAA== To: "Rafael J. Wysocki" <rafael@kernel.org>, Daniel Lezcano <daniel.lezcano@linaro.org>, Amit Kucheria <amitk@kernel.org>, Zhang Rui <rui.zhang@intel.com> Cc: Hugh Dickins <hughd@google.com>, Will Deacon <will@kernel.org>, Icenowy Zheng <uwu@icenowy.me>, Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Samuel Holland <samuel@sholland.org>, linux-sunxi@lists.linux.dev, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>, stable@vger.kernel.org X-Mailer: b4 0.13-dev-099c9 X-Developer-Signature: v=1; a=openpgp-sha256; l=2606; i=broonie@kernel.org; h=from:subject:message-id; bh=C5VTDtOqdmj6Bz6JgxfHCEKJHYyIn7v2H/pyJ1qHGCM=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBkvGXVA478VBnEpmpTCC3lkhtcVWQsWgJ581sVm 3BnS4HC/CyJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZLxl1QAKCRAk1otyXVSH 0JDuB/9a/lDjye3WC1siBtiAlqrJwcRmcgSVvUyChe5ZEPX/NPDNQV2sE4Y/pEBW9r7bEfVgWug tqEcqEuB5WtxrvMT6cCbg3BEFKMjy+JCJFExYChP5N6bJMwqicSzBsfF0YDBC5Th4H6pGTLP9u8 ZHlsg4d/3wYEVC/quGwLSSWgn3CulLd/rFDMzIMkYCc5y6XOChONE8A6Su5Bl+G03bQbY7AIEdL NS9IMolnTV9NYXaJImgQhjn1AhNHrCbosXp5PNQ6ya6ZK7B0OMWOB4Tee6EGDjJRuegJLqa4GhQ pu96tBHNv4NrjuxjnhnBtIPamTSl7r0Yh03594DCXVyhBFVf X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772166942747473729 X-GMAIL-MSGID: 1772166942747473729 |
Series |
thermal/of: Fix double free of params during unregistration
|
|
Commit Message
Mark Brown
July 22, 2023, 11:26 p.m. UTC
Unlike the other data structures provided during registration the
thermal core takes a copy of the thermal_zone_params provided to it and
stores that copy in the thermal_zone_device, taking care to free it on
unregistration. This is done because the parameters will be modified at
runtime.
Unfortunately the thermal_of code assumes that the params structure it
provides will be used throughout the lifetime of the device and since
the params are dynamically allocated based on the bindings it attempts
to free it on unregistration. This results in not only leaking the
original params but also double freeing the copy the core made, leading
to memory corruption.
Fix this by instead freeing the params parsed from the DT during
registration.
This issue causing instability on systems where thermal zones are
unregistered, especially visble on those systems where some zones
provided by a device have no trip points such as Allwinner systems.
For example with current mainline an arm64 defconfig is unbootable on
Pine64 Plus and LibreTech Tritium is massively unstable. These issues
have been there for a while and have been made more prominent by recent
memory management changes.
Fixes: 3fd6d6e2b4e80 ("thermal/of: Rework the thermal device tree initialization")
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
---
drivers/thermal/thermal_of.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
---
base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c
change-id: 20230722-thermal-fix-of-memory-corruption-73c023f8612b
Best regards,
Comments
Hi Mark, On 23/07/2023 01:26, Mark Brown wrote: > Unlike the other data structures provided during registration the > thermal core takes a copy of the thermal_zone_params provided to it and > stores that copy in the thermal_zone_device, taking care to free it on > unregistration. This is done because the parameters will be modified at > runtime. > > Unfortunately the thermal_of code assumes that the params structure it > provides will be used throughout the lifetime of the device and since > the params are dynamically allocated based on the bindings it attempts > to free it on unregistration. This results in not only leaking the > original params but also double freeing the copy the core made, leading > to memory corruption. > > Fix this by instead freeing the params parsed from the DT during > registration. > > This issue causing instability on systems where thermal zones are > unregistered, especially visble on those systems where some zones > provided by a device have no trip points such as Allwinner systems. > For example with current mainline an arm64 defconfig is unbootable on > Pine64 Plus and LibreTech Tritium is massively unstable. These issues > have been there for a while and have been made more prominent by recent > memory management changes. > > Fixes: 3fd6d6e2b4e80 ("thermal/of: Rework the thermal device tree initialization") > Signed-off-by: Mark Brown <broonie@kernel.org> > Cc: stable@vger.kernel.org I think this issue has been fixed by: https://lore.kernel.org/all/20230708112720.2897484-2-a.fatoum@pengutronix.de/ Rafael ? Did you pick it up ?
On Sun, Jul 23, 2023 at 11:57:52AM +0200, Daniel Lezcano wrote: > On 23/07/2023 01:26, Mark Brown wrote: > I think this issue has been fixed by: > https://lore.kernel.org/all/20230708112720.2897484-2-a.fatoum@pengutronix.de/ Yes, that should fix the same issue. > Rafael ? Did you pick it up ? There was a message on the thread saying the patches have been applied for v6.5 but I can't see them in either mainline or -next.
On Sun, Jul 23, 2023 at 4:32 PM Mark Brown <broonie@kernel.org> wrote: > > On Sun, Jul 23, 2023 at 11:57:52AM +0200, Daniel Lezcano wrote: > > On 23/07/2023 01:26, Mark Brown wrote: > > > I think this issue has been fixed by: > > > https://lore.kernel.org/all/20230708112720.2897484-2-a.fatoum@pengutronix.de/ > > Yes, that should fix the same issue. > > > Rafael ? Did you pick it up ? > > There was a message on the thread saying the patches have been applied > for v6.5 but I can't see them in either mainline or -next. They should be there in linux-next (as of today). Surely, they are present in my linux-next branch.
On Wed, Jul 26, 2023 at 08:42:39PM +0200, Rafael J. Wysocki wrote: > On Sun, Jul 23, 2023 at 4:32 PM Mark Brown <broonie@kernel.org> wrote: > > There was a message on the thread saying the patches have been applied > > for v6.5 but I can't see them in either mainline or -next. > They should be there in linux-next (as of today). Yes, they're there now. They weren't at time of writing the above (on Sunday). > Surely, they are present in my linux-next branch. Are they queued as fixes? It'd be really good to get these into v6.5, they're rendering the Allwinner platforms I have unusable.
On Wed, Jul 26, 2023 at 8:47 PM Mark Brown <broonie@kernel.org> wrote: > > On Wed, Jul 26, 2023 at 08:42:39PM +0200, Rafael J. Wysocki wrote: > > On Sun, Jul 23, 2023 at 4:32 PM Mark Brown <broonie@kernel.org> wrote: > > > > There was a message on the thread saying the patches have been applied > > > for v6.5 but I can't see them in either mainline or -next. > > > They should be there in linux-next (as of today). > > Yes, they're there now. They weren't at time of writing the above (on > Sunday). > > > Surely, they are present in my linux-next branch. > > Are they queued as fixes? They are. > It'd be really good to get these into v6.5, > they're rendering the Allwinner platforms I have unusable. I'm going to send a pull request with them tomorrow or on Friday.
On Wed, Jul 26, 2023 at 08:51:20PM +0200, Rafael J. Wysocki wrote: > On Wed, Jul 26, 2023 at 8:47 PM Mark Brown <broonie@kernel.org> wrote: > > > Surely, they are present in my linux-next branch. > > Are they queued as fixes? > They are. > > It'd be really good to get these into v6.5, > > they're rendering the Allwinner platforms I have unusable. > I'm going to send a pull request with them tomorrow or on Friday. Ah, excellent - thanks!
diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c index 6fb14e521197..0af11cdfa2c1 100644 --- a/drivers/thermal/thermal_of.c +++ b/drivers/thermal/thermal_of.c @@ -442,13 +442,11 @@ static int thermal_of_unbind(struct thermal_zone_device *tz, static void thermal_of_zone_unregister(struct thermal_zone_device *tz) { struct thermal_trip *trips = tz->trips; - struct thermal_zone_params *tzp = tz->tzp; struct thermal_zone_device_ops *ops = tz->ops; thermal_zone_device_disable(tz); thermal_zone_device_unregister(tz); kfree(trips); - kfree(tzp); kfree(ops); } @@ -530,6 +528,9 @@ static struct thermal_zone_device *thermal_of_zone_register(struct device_node * goto out_kfree_tzp; } + /* The core will take a copy of tzp, free our copy here. */ + kfree(tzp); + ret = thermal_zone_device_enable(tz); if (ret) { pr_err("Failed to enabled thermal zone '%s', id=%d: %d\n",