From: Chen-Yu Tsai <wenst@chromium.org>
To: Yu-Che Cheng <giver@chromium.org>, Stephen Boyd <sboyd@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>,
linux-kernel@vger.kernel.org, James Lo <james.lo@mediatek.com>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-arm-kernel@lists.infradead.org,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH] spmi: mediatek: Fix UAF on device remove
Date: Mon, 21 Aug 2023 11:35:32 +0800 [thread overview]
Message-ID: <20230821033532.GA21555@google.com> (raw)
In-Reply-To: <20230717173934.1.If004a6e055a189c7f2d0724fa814422c26789839@changeid>
On Mon, Jul 17, 2023 at 05:39:35PM +0800, Yu-Che Cheng wrote:
> The pmif driver data that contains the clocks is allocated along with
> spmi_controller.
> On device remove, spmi_controller will be freed first, and then devres
> , including the clocks, will be cleanup.
> This leads to UAF because putting the clocks will access the clocks in
> the pmif driver data, which is already freed along with spmi_controller.
>
> This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and
> building the kernel with KASAN.
>
> Fix the UAF issue by using unmanaged clk_bulk_get() and putting the
> clocks before freeing spmi_controller.
>
> Reported-by: Fei Shao <fshao@chromium.org>
> Signed-off-by: Yu-Che Cheng <giver@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Stephen, could you pick this up?
> ---
>
> drivers/spmi/spmi-mtk-pmif.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spmi/spmi-mtk-pmif.c b/drivers/spmi/spmi-mtk-pmif.c
> index b3c991e1ea40..74b73f9bc222 100644
> --- a/drivers/spmi/spmi-mtk-pmif.c
> +++ b/drivers/spmi/spmi-mtk-pmif.c
> @@ -465,7 +465,7 @@ static int mtk_spmi_probe(struct platform_device *pdev)
> for (i = 0; i < arb->nclks; i++)
> arb->clks[i].id = pmif_clock_names[i];
>
> - err = devm_clk_bulk_get(&pdev->dev, arb->nclks, arb->clks);
> + err = clk_bulk_get(&pdev->dev, arb->nclks, arb->clks);
> if (err) {
> dev_err(&pdev->dev, "Failed to get clocks: %d\n", err);
> goto err_put_ctrl;
> @@ -474,7 +474,7 @@ static int mtk_spmi_probe(struct platform_device *pdev)
> err = clk_bulk_prepare_enable(arb->nclks, arb->clks);
> if (err) {
> dev_err(&pdev->dev, "Failed to enable clocks: %d\n", err);
> - goto err_put_ctrl;
> + goto err_put_clks;
> }
>
> ctrl->cmd = pmif_arb_cmd;
> @@ -498,6 +498,8 @@ static int mtk_spmi_probe(struct platform_device *pdev)
>
> err_domain_remove:
> clk_bulk_disable_unprepare(arb->nclks, arb->clks);
> +err_put_clks:
> + clk_bulk_put(arb->nclks, arb->clks);
> err_put_ctrl:
> spmi_controller_put(ctrl);
> return err;
> @@ -509,6 +511,7 @@ static void mtk_spmi_remove(struct platform_device *pdev)
> struct pmif *arb = spmi_controller_get_drvdata(ctrl);
>
> clk_bulk_disable_unprepare(arb->nclks, arb->clks);
> + clk_bulk_put(arb->nclks, arb->clks);
> spmi_controller_remove(ctrl);
> spmi_controller_put(ctrl);
Maybe we need devres versions of spmi_controller_alloc and
spmi_controller_add to avoid this in the future? I'm sure
drivers put all sorts of stuff in their private data.
ChenYu
> }
> --
> 2.41.0.255.g8b1d071c50-goog
>
WARNING: multiple messages have this Message-ID (diff)
From: Chen-Yu Tsai <wenst@chromium.org>
To: Yu-Che Cheng <giver@chromium.org>, Stephen Boyd <sboyd@kernel.org>
Cc: James Lo <james.lo@mediatek.com>, Stephen Boyd <sboyd@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Fei Shao <fshao@chromium.org>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] spmi: mediatek: Fix UAF on device remove
Date: Mon, 21 Aug 2023 11:35:32 +0800 [thread overview]
Message-ID: <20230821033532.GA21555@google.com> (raw)
In-Reply-To: <20230717173934.1.If004a6e055a189c7f2d0724fa814422c26789839@changeid>
On Mon, Jul 17, 2023 at 05:39:35PM +0800, Yu-Che Cheng wrote:
> The pmif driver data that contains the clocks is allocated along with
> spmi_controller.
> On device remove, spmi_controller will be freed first, and then devres
> , including the clocks, will be cleanup.
> This leads to UAF because putting the clocks will access the clocks in
> the pmif driver data, which is already freed along with spmi_controller.
>
> This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and
> building the kernel with KASAN.
>
> Fix the UAF issue by using unmanaged clk_bulk_get() and putting the
> clocks before freeing spmi_controller.
>
> Reported-by: Fei Shao <fshao@chromium.org>
> Signed-off-by: Yu-Che Cheng <giver@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Stephen, could you pick this up?
> ---
>
> drivers/spmi/spmi-mtk-pmif.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spmi/spmi-mtk-pmif.c b/drivers/spmi/spmi-mtk-pmif.c
> index b3c991e1ea40..74b73f9bc222 100644
> --- a/drivers/spmi/spmi-mtk-pmif.c
> +++ b/drivers/spmi/spmi-mtk-pmif.c
> @@ -465,7 +465,7 @@ static int mtk_spmi_probe(struct platform_device *pdev)
> for (i = 0; i < arb->nclks; i++)
> arb->clks[i].id = pmif_clock_names[i];
>
> - err = devm_clk_bulk_get(&pdev->dev, arb->nclks, arb->clks);
> + err = clk_bulk_get(&pdev->dev, arb->nclks, arb->clks);
> if (err) {
> dev_err(&pdev->dev, "Failed to get clocks: %d\n", err);
> goto err_put_ctrl;
> @@ -474,7 +474,7 @@ static int mtk_spmi_probe(struct platform_device *pdev)
> err = clk_bulk_prepare_enable(arb->nclks, arb->clks);
> if (err) {
> dev_err(&pdev->dev, "Failed to enable clocks: %d\n", err);
> - goto err_put_ctrl;
> + goto err_put_clks;
> }
>
> ctrl->cmd = pmif_arb_cmd;
> @@ -498,6 +498,8 @@ static int mtk_spmi_probe(struct platform_device *pdev)
>
> err_domain_remove:
> clk_bulk_disable_unprepare(arb->nclks, arb->clks);
> +err_put_clks:
> + clk_bulk_put(arb->nclks, arb->clks);
> err_put_ctrl:
> spmi_controller_put(ctrl);
> return err;
> @@ -509,6 +511,7 @@ static void mtk_spmi_remove(struct platform_device *pdev)
> struct pmif *arb = spmi_controller_get_drvdata(ctrl);
>
> clk_bulk_disable_unprepare(arb->nclks, arb->clks);
> + clk_bulk_put(arb->nclks, arb->clks);
> spmi_controller_remove(ctrl);
> spmi_controller_put(ctrl);
Maybe we need devres versions of spmi_controller_alloc and
spmi_controller_add to avoid this in the future? I'm sure
drivers put all sorts of stuff in their private data.
ChenYu
> }
> --
> 2.41.0.255.g8b1d071c50-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Chen-Yu Tsai <wenst@chromium.org>
To: Yu-Che Cheng <giver@chromium.org>, Stephen Boyd <sboyd@kernel.org>
Cc: James Lo <james.lo@mediatek.com>, Stephen Boyd <sboyd@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Fei Shao <fshao@chromium.org>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] spmi: mediatek: Fix UAF on device remove
Date: Mon, 21 Aug 2023 11:35:32 +0800 [thread overview]
Message-ID: <20230821033532.GA21555@google.com> (raw)
In-Reply-To: <20230717173934.1.If004a6e055a189c7f2d0724fa814422c26789839@changeid>
On Mon, Jul 17, 2023 at 05:39:35PM +0800, Yu-Che Cheng wrote:
> The pmif driver data that contains the clocks is allocated along with
> spmi_controller.
> On device remove, spmi_controller will be freed first, and then devres
> , including the clocks, will be cleanup.
> This leads to UAF because putting the clocks will access the clocks in
> the pmif driver data, which is already freed along with spmi_controller.
>
> This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and
> building the kernel with KASAN.
>
> Fix the UAF issue by using unmanaged clk_bulk_get() and putting the
> clocks before freeing spmi_controller.
>
> Reported-by: Fei Shao <fshao@chromium.org>
> Signed-off-by: Yu-Che Cheng <giver@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Stephen, could you pick this up?
> ---
>
> drivers/spmi/spmi-mtk-pmif.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spmi/spmi-mtk-pmif.c b/drivers/spmi/spmi-mtk-pmif.c
> index b3c991e1ea40..74b73f9bc222 100644
> --- a/drivers/spmi/spmi-mtk-pmif.c
> +++ b/drivers/spmi/spmi-mtk-pmif.c
> @@ -465,7 +465,7 @@ static int mtk_spmi_probe(struct platform_device *pdev)
> for (i = 0; i < arb->nclks; i++)
> arb->clks[i].id = pmif_clock_names[i];
>
> - err = devm_clk_bulk_get(&pdev->dev, arb->nclks, arb->clks);
> + err = clk_bulk_get(&pdev->dev, arb->nclks, arb->clks);
> if (err) {
> dev_err(&pdev->dev, "Failed to get clocks: %d\n", err);
> goto err_put_ctrl;
> @@ -474,7 +474,7 @@ static int mtk_spmi_probe(struct platform_device *pdev)
> err = clk_bulk_prepare_enable(arb->nclks, arb->clks);
> if (err) {
> dev_err(&pdev->dev, "Failed to enable clocks: %d\n", err);
> - goto err_put_ctrl;
> + goto err_put_clks;
> }
>
> ctrl->cmd = pmif_arb_cmd;
> @@ -498,6 +498,8 @@ static int mtk_spmi_probe(struct platform_device *pdev)
>
> err_domain_remove:
> clk_bulk_disable_unprepare(arb->nclks, arb->clks);
> +err_put_clks:
> + clk_bulk_put(arb->nclks, arb->clks);
> err_put_ctrl:
> spmi_controller_put(ctrl);
> return err;
> @@ -509,6 +511,7 @@ static void mtk_spmi_remove(struct platform_device *pdev)
> struct pmif *arb = spmi_controller_get_drvdata(ctrl);
>
> clk_bulk_disable_unprepare(arb->nclks, arb->clks);
> + clk_bulk_put(arb->nclks, arb->clks);
> spmi_controller_remove(ctrl);
> spmi_controller_put(ctrl);
Maybe we need devres versions of spmi_controller_alloc and
spmi_controller_add to avoid this in the future? I'm sure
drivers put all sorts of stuff in their private data.
ChenYu
> }
> --
> 2.41.0.255.g8b1d071c50-goog
>
next prev parent reply other threads:[~2023-08-21 3:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-17 9:39 [PATCH] spmi: mediatek: Fix UAF on device remove Yu-Che Cheng
2023-07-17 9:39 ` Yu-Che Cheng
2023-07-18 6:57 ` Fei Shao
2023-07-18 6:57 ` Fei Shao
2023-08-18 5:09 ` Fei Shao
2023-08-18 5:09 ` Fei Shao
2023-08-21 3:35 ` Chen-Yu Tsai [this message]
2023-08-21 3:35 ` Chen-Yu Tsai
2023-08-21 3:35 ` Chen-Yu Tsai
2023-08-21 6:18 ` Fei Shao
2023-08-21 6:18 ` Fei Shao
2023-10-24 2:01 ` Stephen Boyd
2023-10-24 2:01 ` Stephen Boyd
2023-10-24 2:01 ` Stephen Boyd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230821033532.GA21555@google.com \
--to=wenst@chromium.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=giver@chromium.org \
--cc=james.lo@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.