Message ID | 20230524-opp-lazy-uaf-v2-1-c26304544a47@kernkonzept.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2288914vqr; Tue, 30 May 2023 09:04:32 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4gKdb7pphY1AG6wE1qMD62VImzFQUXp2/c1xUrEL7HqSuFnCACFRYwDoi9zLPyPK7nVrVb X-Received: by 2002:a17:90a:5801:b0:253:266a:3b00 with SMTP id h1-20020a17090a580100b00253266a3b00mr3075673pji.37.1685462672345; Tue, 30 May 2023 09:04:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685462672; cv=none; d=google.com; s=arc-20160816; b=OyuWvKYYA5pj7i7aoc7KhsTxfb0yFTT8oC0Iip37H518BkAmf6DTbD7G5F8/E0bEIj NxAjWnBYeLb9ZtdMxVX5kGw6gjlqb6eeJRfjs160akM4c9QWaePEA/9eYaFEmBEnzVT6 HIS/PW2v9HNHzLYw9arIjt7m/3IKvdHzARt5CF02BRE9yIYaeNMuCVmh84GcJadet1Sg AyyetuZgda0wkm8XGZdF8ecmpnJa4SxLA/OKVvcWTOZn+o4olV4d7yz70nXgGdFUPzjG o9nmwMDoGjuF16pMWZu0RSKl02LukvOtt6v+SSnxrWS1sD4J4FjwBPH5caT8raPWIDJa OCvA== 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=jb0TWNMdj00Yo7l1c5KV/Xu5496JxdVZgvDLfmprk18=; b=R479gLbJ4KEY8EXF7SShlFnXu65RbWDgJFY3ukQZLFcWLsVn7RgnT0okQiDVhEUrhY 55ZrXhp4RjPliMHI2hrf1VdjCWnY0Qxvy8lwGuCcB9dQdTGIopWi9REwN/WJbvb7YyDD JBuBH2gs5KHV6Nr0FvdGzumcOogsy1Ct61MP+B5AZ+F8NC2E31LTsZJdhY/EffnvAQh5 /yGMPFe7GeJizLT0ZpB6gAosoGFkzKEhVcq5yzCujr1DMMRTabI7T2Eg3s3dq5tchFu/ Mz4I4oKLryXdrxKVndgJbKLT2DdhyVByNVqveK2EKqNQ7AWU6WH6AK7YGzVi++EX6+N1 ZYOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernkonzept.com header.s=mx1 header.b=oDIO6Ui9; 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=kernkonzept.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i1-20020a17090a65c100b002536c5eb7cfsi7260146pjs.58.2023.05.30.09.04.11; Tue, 30 May 2023 09:04:32 -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=@kernkonzept.com header.s=mx1 header.b=oDIO6Ui9; 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=kernkonzept.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232656AbjE3Pz2 (ORCPT <rfc822;andrewvogler123@gmail.com> + 99 others); Tue, 30 May 2023 11:55:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232812AbjE3Py4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 30 May 2023 11:54:56 -0400 Received: from mx.kernkonzept.com (serv1.kernkonzept.com [IPv6:2a01:4f8:1c1c:b490::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26F64C5; Tue, 30 May 2023 08:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kernkonzept.com; s=mx1; h=Cc:To:Message-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:Subject:Date:From:References:In-Reply-To:Reply-To: Content-ID:Content-Description; bh=jb0TWNMdj00Yo7l1c5KV/Xu5496JxdVZgvDLfmprk18=; b=oDIO6Ui9TmTc1K+WBD770C45IN fL9bAvFFVSpuZ6INoZVmvn4v1+zfvjUGyOuM+R4blZPATfbhi7VER3VJ0chV2WLiHLulJmUEakwwL 0GzE+AEQADt+HDS7/giYRi0MJO+fcyyFZGnKCyHu9c3vqHvScF2WxxjJWlJ9MLUioO5Ag4xfH2Gm5 +UKHUcv+cdUZKSWTeYGD7pl5ThL9ya4RcCQZwg1B2ji0ZsWXmki81VItTFxErIpV87QD8QJZqJCS5 b7IeeqsJwzyZWaVtOEaIg1yD2PIeImA3k1pKmJaNebWmRt154g3SAnMh50w0WzB4IRvLf6frMRMCV lhwkUGDQ==; Received: from [10.22.3.24] (helo=serv1.dd1.int.kernkonzept.com) by mx.kernkonzept.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) id 1q41gP-003j9c-UX; Tue, 30 May 2023 17:54:49 +0200 From: Stephan Gerhold <stephan.gerhold@kernkonzept.com> Date: Tue, 30 May 2023 17:54:46 +0200 Subject: [PATCH v2] opp: Fix use-after-free in lazy_opp_tables after probe deferral MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230524-opp-lazy-uaf-v2-1-c26304544a47@kernkonzept.com> X-B4-Tracking: v=1; b=H4sIAEUcdmQC/3WNwQ6CMBAFf8Xs2TWlUKKe/A/DoS1bacC2aYEIh H+3cvc4k7w3GySKlhLcTxtEmm2y3mXg5xPoTroXoW0zA2e8ZIJX6EPAQa4LTtJgzSRjlSqvgjT kiZKJUEXpdJdHbhqGLEMkYz9H49lk7mwafVyO5Fz87J/3ucACjTA3oVWl6pYePUXXe7dSGC/av 6HZ9/0LG9gCXMMAAAA= To: Viresh Kumar <vireshk@kernel.org> Cc: Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@kernel.org>, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Viresh Kumar <viresh.kumar@linaro.org>, Stephan Gerhold <stephan.gerhold@kernkonzept.com> X-Mailer: b4 0.12.2 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767335706707033755?= X-GMAIL-MSGID: =?utf-8?q?1767335706707033755?= |
Series |
[v2] opp: Fix use-after-free in lazy_opp_tables after probe deferral
|
|
Commit Message
Stephan Gerhold
May 30, 2023, 3:54 p.m. UTC
When dev_pm_opp_of_find_icc_paths() in _allocate_opp_table() returns
-EPROBE_DEFER, the opp_table is freed again, to wait until all the
interconnect paths are available.
However, if the OPP table is using required-opps then it may already
have been added to the global lazy_opp_tables list. The error path
does not remove the opp_table from the list again.
This can cause crashes later when the provider of the required-opps
is added, since we will iterate over OPP tables that have already been
freed. E.g.:
Unable to handle kernel NULL pointer dereference when read
CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3
PC is at _of_add_opp_table_v2 (include/linux/of.h:949
drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404
drivers/opp/of.c:1032) -> lazy_link_required_opp_table()
Fix this by calling _of_clear_opp_table() to remove the opp_table from
the list and clear other allocated resources. While at it, also add the
missing mutex_destroy() calls in the error path.
Cc: stable@vger.kernel.org
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Fixes: 7eba0c7641b0 ("opp: Allow lazy-linking of required-opps")
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
---
Changes in v2:
- Call _of_clear_opp_table() as suggested by Viresh
- Also add missing mutex_destroy() calls in the error path
- Link to v1: https://lore.kernel.org/r/20230524-opp-lazy-uaf-v1-1-f5f95cb4b6de@kernkonzept.com
---
This fixes the crash I ran into after adding an OPP table with
both "required-opps" and interconnect paths (opp-peak-kBps).
---
drivers/opp/core.c | 3 +++
1 file changed, 3 insertions(+)
---
base-commit: 9e28f7a74581204807f20ae46568939038e327aa
change-id: 20230524-opp-lazy-uaf-60a004b385ec
Best regards,
Comments
On 30-05-23, 17:54, Stephan Gerhold wrote: > When dev_pm_opp_of_find_icc_paths() in _allocate_opp_table() returns > -EPROBE_DEFER, the opp_table is freed again, to wait until all the > interconnect paths are available. > > However, if the OPP table is using required-opps then it may already > have been added to the global lazy_opp_tables list. The error path > does not remove the opp_table from the list again. > > This can cause crashes later when the provider of the required-opps > is added, since we will iterate over OPP tables that have already been > freed. E.g.: > > Unable to handle kernel NULL pointer dereference when read > CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3 > PC is at _of_add_opp_table_v2 (include/linux/of.h:949 > drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404 > drivers/opp/of.c:1032) -> lazy_link_required_opp_table() > > Fix this by calling _of_clear_opp_table() to remove the opp_table from > the list and clear other allocated resources. While at it, also add the > missing mutex_destroy() calls in the error path. > > Cc: stable@vger.kernel.org > Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> > Fixes: 7eba0c7641b0 ("opp: Allow lazy-linking of required-opps") > Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com> > --- > Changes in v2: > - Call _of_clear_opp_table() as suggested by Viresh > - Also add missing mutex_destroy() calls in the error path > - Link to v1: https://lore.kernel.org/r/20230524-opp-lazy-uaf-v1-1-f5f95cb4b6de@kernkonzept.com > --- > This fixes the crash I ran into after adding an OPP table with > both "required-opps" and interconnect paths (opp-peak-kBps). > --- > drivers/opp/core.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > index 85cbc8de407c..7046487dc6f4 100644 > --- a/drivers/opp/core.c > +++ b/drivers/opp/core.c > @@ -1358,7 +1358,10 @@ static struct opp_table *_allocate_opp_table(struct device *dev, int index) > return opp_table; > > remove_opp_dev: > + _of_clear_opp_table(opp_table); > _remove_opp_dev(opp_dev, opp_table); > + mutex_destroy(&opp_table->genpd_virt_dev_lock); > + mutex_destroy(&opp_table->lock); > err: > kfree(opp_table); > return ERR_PTR(ret); > Applied. Thanks.
diff --git a/drivers/opp/core.c b/drivers/opp/core.c index 85cbc8de407c..7046487dc6f4 100644 --- a/drivers/opp/core.c +++ b/drivers/opp/core.c @@ -1358,7 +1358,10 @@ static struct opp_table *_allocate_opp_table(struct device *dev, int index) return opp_table; remove_opp_dev: + _of_clear_opp_table(opp_table); _remove_opp_dev(opp_dev, opp_table); + mutex_destroy(&opp_table->genpd_virt_dev_lock); + mutex_destroy(&opp_table->lock); err: kfree(opp_table); return ERR_PTR(ret);