All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Masney <bmasney@redhat.com>
To: Conor Dooley <conor@kernel.org>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	linux-clk@vger.kernel.org, stable@vger.kernel.org,
	Daire McNamara <daire.mcnamara@microchip.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] clk: microchip: mpfs-ccc: fix out of bounds access during output registration
Date: Thu, 26 Feb 2026 10:38:45 -0500	[thread overview]
Message-ID: <aaBpBYVtt_VhuJws@redhat.com> (raw)
In-Reply-To: <20260225-thrive-endless-3168e0b0f916@spud>

On Wed, Feb 25, 2026 at 11:24:59PM +0000, Conor Dooley wrote:
> On Wed, Feb 25, 2026 at 11:14:47PM +0000, Conor Dooley wrote:
> > On Wed, Feb 25, 2026 at 05:56:53PM -0500, Brian Masney wrote:
> > > Hi Conor,
> > > 
> > > On Tue, Feb 24, 2026 at 09:35:25AM +0000, Conor Dooley wrote:
> > > > UBSAN reported an out of bounds access during registration of the last
> > > > two outputs. This out of bounds access occurs because space is only
> > > > allocated in the hws array for two PLLs and the four output dividers
> > > > that each has, but the defined IDs contain two DLLS and their two
> > > > outputs each, which are not supported by the driver. The ID order is
> > > > PLLs -> DLLs -> PLL outputs -> DLL outputs. Decrement the PLL output IDs
> > > > by two while adding them to the array to avoid the problem.
> > > > 
> > > > Fixes: d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support")
> > > > CC: stable@vger.kernel.org
> > > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > > > ---
> > > > CC: Conor Dooley <conor.dooley@microchip.com>
> > > > CC: Daire McNamara <daire.mcnamara@microchip.com>
> > > > CC: Michael Turquette <mturquette@baylibre.com>
> > > > CC: Stephen Boyd <sboyd@kernel.org>
> > > > CC: Claudiu Beznea <claudiu.beznea@tuxon.dev>
> > > > CC: linux-riscv@lists.infradead.org
> > > > CC: linux-clk@vger.kernel.org
> > > > CC: linux-kernel@vger.kernel.org
> > > > ---
> > > >  drivers/clk/microchip/clk-mpfs-ccc.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/clk/microchip/clk-mpfs-ccc.c b/drivers/clk/microchip/clk-mpfs-ccc.c
> > > > index 3a3ea2d142f8a..54cfbb8be8ab5 100644
> > > > --- a/drivers/clk/microchip/clk-mpfs-ccc.c
> > > > +++ b/drivers/clk/microchip/clk-mpfs-ccc.c
> > > > @@ -178,7 +178,7 @@ static int mpfs_ccc_register_outputs(struct device *dev, struct mpfs_ccc_out_hw_
> > > >  			return dev_err_probe(dev, ret, "failed to register clock id: %d\n",
> > > >  					     out_hw->id);
> > > >  
> > > > -		data->hw_data.hws[out_hw->id] = &out_hw->divider.hw;
> > > > +		data->hw_data.hws[out_hw->id - 2] = &out_hw->divider.hw;
> > > 
> > > What happens when / if the DLLs are supported by this driver in the
> > > future? This seems like a trap for the future.
> > > 
> > > According to include/dt-bindings/clock/microchip,mpfs-clock.h, there are
> > > only 16 clock IDs. Could hws be initialized to have enough room for all
> > > 16 structures, and would it be ok if it was a sparse array?
> > > 
> > > At the very least, I think it would be nice to include a comment here.
> > 
> > I think I'd rather add a comment, I know it's at most only 24 extra
> > allocations, but just feels bad to do it.
> 
> I'll add this, maybe on application.
> 
> @@ -234,6 +234,10 @@ static int mpfs_ccc_probe(struct platform_device *pdev)
>         unsigned int num_clks;
>         int ret;
>  
> +       /*
> +        * If DLLs get added here, mpfs_ccc_register_outputs() currently packs
> +        * sparse clock IDs in the hws array
> +        */
>         num_clks = ARRAY_SIZE(mpfs_ccc_pll_clks) + ARRAY_SIZE(mpfs_ccc_pll0out_clks) +
>                    ARRAY_SIZE(mpfs_ccc_pll1out_clks);

That makes sense.

Reviewed-by: Brian Masney <bmasney@redhat.com>


WARNING: multiple messages have this Message-ID (diff)
From: Brian Masney <bmasney@redhat.com>
To: Conor Dooley <conor@kernel.org>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	linux-clk@vger.kernel.org, stable@vger.kernel.org,
	Daire McNamara <daire.mcnamara@microchip.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] clk: microchip: mpfs-ccc: fix out of bounds access during output registration
Date: Thu, 26 Feb 2026 10:38:45 -0500	[thread overview]
Message-ID: <aaBpBYVtt_VhuJws@redhat.com> (raw)
In-Reply-To: <20260225-thrive-endless-3168e0b0f916@spud>

On Wed, Feb 25, 2026 at 11:24:59PM +0000, Conor Dooley wrote:
> On Wed, Feb 25, 2026 at 11:14:47PM +0000, Conor Dooley wrote:
> > On Wed, Feb 25, 2026 at 05:56:53PM -0500, Brian Masney wrote:
> > > Hi Conor,
> > > 
> > > On Tue, Feb 24, 2026 at 09:35:25AM +0000, Conor Dooley wrote:
> > > > UBSAN reported an out of bounds access during registration of the last
> > > > two outputs. This out of bounds access occurs because space is only
> > > > allocated in the hws array for two PLLs and the four output dividers
> > > > that each has, but the defined IDs contain two DLLS and their two
> > > > outputs each, which are not supported by the driver. The ID order is
> > > > PLLs -> DLLs -> PLL outputs -> DLL outputs. Decrement the PLL output IDs
> > > > by two while adding them to the array to avoid the problem.
> > > > 
> > > > Fixes: d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support")
> > > > CC: stable@vger.kernel.org
> > > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > > > ---
> > > > CC: Conor Dooley <conor.dooley@microchip.com>
> > > > CC: Daire McNamara <daire.mcnamara@microchip.com>
> > > > CC: Michael Turquette <mturquette@baylibre.com>
> > > > CC: Stephen Boyd <sboyd@kernel.org>
> > > > CC: Claudiu Beznea <claudiu.beznea@tuxon.dev>
> > > > CC: linux-riscv@lists.infradead.org
> > > > CC: linux-clk@vger.kernel.org
> > > > CC: linux-kernel@vger.kernel.org
> > > > ---
> > > >  drivers/clk/microchip/clk-mpfs-ccc.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/clk/microchip/clk-mpfs-ccc.c b/drivers/clk/microchip/clk-mpfs-ccc.c
> > > > index 3a3ea2d142f8a..54cfbb8be8ab5 100644
> > > > --- a/drivers/clk/microchip/clk-mpfs-ccc.c
> > > > +++ b/drivers/clk/microchip/clk-mpfs-ccc.c
> > > > @@ -178,7 +178,7 @@ static int mpfs_ccc_register_outputs(struct device *dev, struct mpfs_ccc_out_hw_
> > > >  			return dev_err_probe(dev, ret, "failed to register clock id: %d\n",
> > > >  					     out_hw->id);
> > > >  
> > > > -		data->hw_data.hws[out_hw->id] = &out_hw->divider.hw;
> > > > +		data->hw_data.hws[out_hw->id - 2] = &out_hw->divider.hw;
> > > 
> > > What happens when / if the DLLs are supported by this driver in the
> > > future? This seems like a trap for the future.
> > > 
> > > According to include/dt-bindings/clock/microchip,mpfs-clock.h, there are
> > > only 16 clock IDs. Could hws be initialized to have enough room for all
> > > 16 structures, and would it be ok if it was a sparse array?
> > > 
> > > At the very least, I think it would be nice to include a comment here.
> > 
> > I think I'd rather add a comment, I know it's at most only 24 extra
> > allocations, but just feels bad to do it.
> 
> I'll add this, maybe on application.
> 
> @@ -234,6 +234,10 @@ static int mpfs_ccc_probe(struct platform_device *pdev)
>         unsigned int num_clks;
>         int ret;
>  
> +       /*
> +        * If DLLs get added here, mpfs_ccc_register_outputs() currently packs
> +        * sparse clock IDs in the hws array
> +        */
>         num_clks = ARRAY_SIZE(mpfs_ccc_pll_clks) + ARRAY_SIZE(mpfs_ccc_pll0out_clks) +
>                    ARRAY_SIZE(mpfs_ccc_pll1out_clks);

That makes sense.

Reviewed-by: Brian Masney <bmasney@redhat.com>


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-02-26 15:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24  9:35 [PATCH v1] clk: microchip: mpfs-ccc: fix out of bounds access during output registration Conor Dooley
2026-02-24  9:35 ` Conor Dooley
2026-02-25 22:56 ` Brian Masney
2026-02-25 22:56   ` Brian Masney
2026-02-25 23:14   ` Conor Dooley
2026-02-25 23:14     ` Conor Dooley
2026-02-25 23:24     ` Conor Dooley
2026-02-25 23:24       ` Conor Dooley
2026-02-26 15:38       ` Brian Masney [this message]
2026-02-26 15:38         ` Brian Masney
2026-03-02 17:13         ` Conor Dooley
2026-03-02 17:13           ` Conor Dooley

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=aaBpBYVtt_VhuJws@redhat.com \
    --to=bmasney@redhat.com \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=daire.mcnamara@microchip.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@kernel.org \
    --cc=stable@vger.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.