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;
MIME-Version: 1.0
References: <CGME20221213113259eucas1p1c224898772bc5e59de90c1aa65a34de0@eucas1p1.samsung.com>
 <1670311341-32664-1-git-send-email-u0084500@gmail.com> <dd329b51-f11a-2af6-9549-c8a014fd5a71@samsung.com>
In-Reply-To: <dd329b51-f11a-2af6-9549-c8a014fd5a71@samsung.com>
From:   ChiYuan Huang <u0084500@gmail.com>
Date:   Tue, 13 Dec 2022 22:19:06 +0800
Message-ID: <CADiBU39-FUD787RmV9Z+jsSrb2Se66A6FrLWGxf78q2Ud-SrjA@mail.gmail.com>
Subject: Re: [PATCH v2] regulator: core: Use different devices for resource
 allocation and DT lookup
To:     Marek Szyprowski <m.szyprowski@samsung.com>
Cc:     broonie@kernel.org, djrscally@gmail.com, hdegoede@redhat.com,
        markgross@kernel.org, lgirdwood@gmail.com,
        mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
        yangyingliang@huawei.com, gene_chen@richtek.com,
        chiaen_wu@richtek.com, platform-driver-x86@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        linux-stm32@st-md-mailman.stormreply.com,
        linux-arm-kernel@lists.infradead.org,
        ChiYuan Huang <cy_huang@richtek.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

HI,

Marek Szyprowski <m.szyprowski@samsung.com> =E6=96=BC 2022=E5=B9=B412=E6=9C=
=8813=E6=97=A5 =E9=80=B1=E4=BA=8C =E6=99=9A=E4=B8=8A7:33=E5=AF=AB=E9=81=93=
=EF=BC=9A
>
> Dear All,
>
> On 06.12.2022 08:22, cy_huang wrote:
> > From: ChiYuan Huang <cy_huang@richtek.com>
> >
> > Following by the below discussion, there's the potential UAF issue
> > between regulator and mfd.
> > https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huaw=
ei.com/
> >
> > >From the analysis of Yingliang
> >
> > CPU A                         |CPU B
> > mt6370_probe()                        |
> >    devm_mfd_add_devices()     |
> >                               |mt6370_regulator_probe()
> >                               |  regulator_register()
> >                               |    //allocate init_data and add it to d=
evres
> >                               |    regulator_of_get_init_data()
> > i2c_unregister_device()               |
> >    device_del()                       |
> >      devres_release_all()     |
> >        // init_data is freed  |
> >        release_nodes()                |
> >                               |  // using init_data causes UAF
> >                               |  regulator_register()
> >
> > It's common to use mfd core to create child device for the regulator.
> > In order to do the DT lookup for init data, the child that registered
> > the regulator would pass its parent as the parameter. And this causes
> > init data resource allocated to its parent, not itself. The issue happe=
n
> > when parent device is going to release and regulator core is still doin=
g
> > some operation of init data constraint for the regulator of child devic=
e.
> >
> > To fix it, this patch expand 'regulator_register' API to use the
> > different devices for init data allocation and DT lookup.
> >
> > Reported-by: Yang Yingliang <yangyingliang@huawei.com>
> > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
>
>
> This patch landed in linux-next 202212 as commit 8f3cbcd6b440
> ("regulator: core: Use different devices for resource allocation and DT
> lookup"). Unfortunately it causes serious regression on my test systems.
> It looks that some supplies are not resolved correctly and then turned
> off as 'unused', even if they provide power to other core regulators in
> the system. I've observed this issue on Samsung Chromebook Peach-Pit and
> Peach-Pi (ARM 32bit Exynos based). The symptoms are somehow similar to
> the issue reported here some time ago:
>
> https://lore.kernel.org/all/58b92e75-f373-dae7-7031-8abd465bb874@samsung.=
com/
>
> I've post more information once I analyze this issue further.
>
It seems the issue occurs in 'regulator register' resolve supply.
Due to the parent device don't have the of_node, to resolve the
supply, it may need to get the
dt node by recursively finding child regulator.
Like this
parent {
  regulators {
     xxx-supply =3D <&vdd12-ldo>;
     vdd12-ldo: vdd12-ldo {
         regulator-name =3D "xxx";
         regulator-min-microvolts =3D <xxxxx>;
         regulator-max-microvolts =3D <xxxxx>;
      }
  };
};
From this case, 'resolve supply' need to parse at least the more top
level like 'regulators'.
But now, it only take 'vdd12-ldo' as the node or its child to parse its sup=
ply.

Below's the fix I guess.
It'll make the parent of the regulator the same as the dev parameter
in 'regulator_config'.

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ea4a720..7c5036e 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -5526,7 +5526,7 @@ regulator_register(struct device *dev,

        /* register with sysfs */
        rdev->dev.class =3D &regulator_class;
-       rdev->dev.parent =3D dev;
+       rdev->dev.parent =3D config->dev;
        dev_set_name(&rdev->dev, "regulator.%lu",
                    (unsigned long) atomic_inc_return(&regulator_no));
        dev_set_drvdata(&rdev->dev, rdev);

I don't have the board. Could you help to test this change to see
whether it's been fixed or not?
>
> > ---
> > loop Yang Yingliang in cc list.
> >
> > Since v2
> > - Fix typo 'int3742' to 'int3472' for kernel build test
> >
> > ---
> >   drivers/platform/x86/intel/int3472/clk_and_regulator.c | 3 ++-
> >   drivers/regulator/core.c                               | 8 ++++----
> >   drivers/regulator/devres.c                             | 2 +-
> >   drivers/regulator/of_regulator.c                       | 2 +-
> >   drivers/regulator/stm32-vrefbuf.c                      | 2 +-
> >   include/linux/regulator/driver.h                       | 3 ++-
> >   6 files changed, 11 insertions(+), 9 deletions(-)
> >
> > ...
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>