drivers/firmware/arm_scmi/power.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
scmi_power_name_get() does not validate the domain number passed by the
external caller, which may lead to an out-of-bounds access.
Fix this by returning "unknown" for invalid domains, like
scmi_reset_name_get() does.
Fixes: 76a6550990e296a7 ("firmware: arm_scmi: add initial support for power protocol")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/firmware/arm_scmi/power.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
index 3aa84ceb6d2bab68..4a7215e02dec035d 100644
--- a/drivers/firmware/arm_scmi/power.c
+++ b/drivers/firmware/arm_scmi/power.c
@@ -204,8 +204,12 @@ scmi_power_name_get(const struct scmi_protocol_handle *ph,
u32 domain)
{
struct scmi_power_info *pi = ph->get_priv(ph);
- struct power_dom_info *dom = pi->dom_info + domain;
+ struct power_dom_info *dom;
+
+ if (domain >= pi->num_domains)
+ return "unknown";
+ dom = pi->dom_info + domain;
return dom->name;
}
--
2.43.0On Fri, 15 May 2026 11:59:15 +0200, Geert Uytterhoeven wrote:
> scmi_power_name_get() does not validate the domain number passed by the
> external caller, which may lead to an out-of-bounds access.
>
> Fix this by returning "unknown" for invalid domains, like
> scmi_reset_name_get() does.
>
>
> [...]
Applied to sudeep.holla/linux (for-next/scmi/updates), thanks!
[1/1] firmware: arm_scmi: Fix OOB in scmi_power_name_get()
https://git.kernel.org/sudeep.holla/c/f9ef3f66f4b1
--
Regards,
Sudeep
On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote:
> scmi_power_name_get() does not validate the domain number passed by the
> external caller, which may lead to an out-of-bounds access.
>
> Fix this by returning "unknown" for invalid domains, like
> scmi_reset_name_get() does.
>
> Fixes: 76a6550990e296a7 ("firmware: arm_scmi: add initial support for power protocol")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/firmware/arm_scmi/power.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
> index 3aa84ceb6d2bab68..4a7215e02dec035d 100644
> --- a/drivers/firmware/arm_scmi/power.c
> +++ b/drivers/firmware/arm_scmi/power.c
> @@ -204,8 +204,12 @@ scmi_power_name_get(const struct scmi_protocol_handle *ph,
> u32 domain)
> {
> struct scmi_power_info *pi = ph->get_priv(ph);
> - struct power_dom_info *dom = pi->dom_info + domain;
> + struct power_dom_info *dom;
> +
> + if (domain >= pi->num_domains)
> + return "unknown";
>
The only user of this function must not call it for domain >= pi->num_domains.
However, I am thinking if it is bit inconsistent within SCMI core now. I like
the way pinmux/ctl handles this as I don't like the alternative for this
(i.e. ERRPTR(-EINVAL or something)). Worst case if this ever causes issue
we can change the signature of the scmi_{power,reset}_name_get to follow
something like pinmux and update the users. Thoughts ? Happy to apply this
for now.
--
Regards,
Sudeep
Hi Sudeep,
On Thu, 21 May 2026 at 18:26, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote:
> > scmi_power_name_get() does not validate the domain number passed by the
> > external caller, which may lead to an out-of-bounds access.
> >
> > Fix this by returning "unknown" for invalid domains, like
> > scmi_reset_name_get() does.
> >
> > Fixes: 76a6550990e296a7 ("firmware: arm_scmi: add initial support for power protocol")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > drivers/firmware/arm_scmi/power.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
> > index 3aa84ceb6d2bab68..4a7215e02dec035d 100644
> > --- a/drivers/firmware/arm_scmi/power.c
> > +++ b/drivers/firmware/arm_scmi/power.c
> > @@ -204,8 +204,12 @@ scmi_power_name_get(const struct scmi_protocol_handle *ph,
> > u32 domain)
> > {
> > struct scmi_power_info *pi = ph->get_priv(ph);
> > - struct power_dom_info *dom = pi->dom_info + domain;
> > + struct power_dom_info *dom;
> > +
> > + if (domain >= pi->num_domains)
> > + return "unknown";
>
> The only user of this function must not call it for domain >= pi->num_domains.
> However, I am thinking if it is bit inconsistent within SCMI core now. I like
> the way pinmux/ctl handles this as I don't like the alternative for this
> (i.e. ERRPTR(-EINVAL or something)). Worst case if this ever causes issue
> we can change the signature of the scmi_{power,reset}_name_get to follow
> something like pinmux and update the users. Thoughts ? Happy to apply this
> for now.
You mean returning an int error code using return statements, and
returning the objects using passed function pointers?
Depends on the number of returned objects: if it's just one (e.g. a
name or info pointer), then the valid pointer/error pointer idiom is
very common in Linux.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, May 22, 2026 at 09:56:32AM +0200, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Thu, 21 May 2026 at 18:26, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote:
> > > scmi_power_name_get() does not validate the domain number passed by the
> > > external caller, which may lead to an out-of-bounds access.
> > >
> > > Fix this by returning "unknown" for invalid domains, like
> > > scmi_reset_name_get() does.
> > >
> > > Fixes: 76a6550990e296a7 ("firmware: arm_scmi: add initial support for power protocol")
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > > drivers/firmware/arm_scmi/power.c | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
> > > index 3aa84ceb6d2bab68..4a7215e02dec035d 100644
> > > --- a/drivers/firmware/arm_scmi/power.c
> > > +++ b/drivers/firmware/arm_scmi/power.c
> > > @@ -204,8 +204,12 @@ scmi_power_name_get(const struct scmi_protocol_handle *ph,
> > > u32 domain)
> > > {
> > > struct scmi_power_info *pi = ph->get_priv(ph);
> > > - struct power_dom_info *dom = pi->dom_info + domain;
> > > + struct power_dom_info *dom;
> > > +
> > > + if (domain >= pi->num_domains)
> > > + return "unknown";
> >
> > The only user of this function must not call it for domain >= pi->num_domains.
> > However, I am thinking if it is bit inconsistent within SCMI core now. I like
> > the way pinmux/ctl handles this as I don't like the alternative for this
> > (i.e. ERRPTR(-EINVAL or something)). Worst case if this ever causes issue
> > we can change the signature of the scmi_{power,reset}_name_get to follow
> > something like pinmux and update the users. Thoughts ? Happy to apply this
> > for now.
>
> You mean returning an int error code using return statements, and
> returning the objects using passed function pointers?
>
Yes I was thinking so, scmi pinmux seem to follow that.
> Depends on the number of returned objects: if it's just one (e.g. a
> name or info pointer), then the valid pointer/error pointer idiom is
> very common in Linux.
>
Makes sense, I have applied it now. Thanks!
--
Regards,
Sudeep
On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote: > scmi_power_name_get() does not validate the domain number passed by the > external caller, which may lead to an out-of-bounds access. > Is an external caller an out of tree caller? So far as I can see this is only called by scmi_pm_domain_probe(). scmi_pd->name = power_ops->name_get(ph, i); where i < num_domains. regards, dan carpenter
Hi Dan,
On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote:
> On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote:
> > scmi_power_name_get() does not validate the domain number passed by the
> > external caller, which may lead to an out-of-bounds access.
>
> Is an external caller an out of tree caller? So far as I can see this
I meant a caller outside drivers/firmware/arm_scmi/.
> is only called by scmi_pm_domain_probe().
>
> scmi_pd->name = power_ops->name_get(ph, i);
>
> where i < num_domains.
You are right. But this seems to be only API implementation in
drivers/firmware/arm_scmi/ that does not validate the passed domain
number.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, May 15, 2026 at 01:29:27PM +0200, Geert Uytterhoeven wrote: > Hi Dan, > Hi all, > On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote: > > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote: > > > scmi_power_name_get() does not validate the domain number passed by the > > > external caller, which may lead to an out-of-bounds access. > > > > Is an external caller an out of tree caller? So far as I can see this > > I meant a caller outside drivers/firmware/arm_scmi/. > > > is only called by scmi_pm_domain_probe(). > > > > scmi_pd->name = power_ops->name_get(ph, i); > > > > where i < num_domains. > > You are right. But this seems to be only API implementation in > drivers/firmware/arm_scmi/ that does not validate the passed domain > number. > Yes we tend to validate protocol operations calls even if apparently safe from teh caller perspective...indeed I have this fixed locally since ages in an horrible patch, that does a lot more, and that I never posted :P Usually, if it is worth, we also build an internal domain get helper to reuse across the protocol unit...but here really there are only 2 call-sites. What I am not sure is what to return: "unknown" is safer as of now than NULL for sure, but really, what happened is NOT that the name was "unknown" (which by itself would be out-of-spec behaviour) it is more that the whole domain that was referred to that was invalid and NOT existent... ....mmm I suppose we are opening another can of worms here :P Thanks, Cristian
Hi Cristian,
On Fri, 15 May 2026 at 13:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> On Fri, May 15, 2026 at 01:29:27PM +0200, Geert Uytterhoeven wrote:
> > On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote:
> > > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote:
> > > > scmi_power_name_get() does not validate the domain number passed by the
> > > > external caller, which may lead to an out-of-bounds access.
> > >
> > > Is an external caller an out of tree caller? So far as I can see this
> >
> > I meant a caller outside drivers/firmware/arm_scmi/.
> >
> > > is only called by scmi_pm_domain_probe().
> > >
> > > scmi_pd->name = power_ops->name_get(ph, i);
> > >
> > > where i < num_domains.
> >
> > You are right. But this seems to be only API implementation in
> > drivers/firmware/arm_scmi/ that does not validate the passed domain
> > number.
>
> Yes we tend to validate protocol operations calls even if apparently
> safe from teh caller perspective...indeed I have this fixed locally
> since ages in an horrible patch, that does a lot more, and that I
> never posted :P
>
> Usually, if it is worth, we also build an internal domain get helper to
> reuse across the protocol unit...but here really there are only 2 call-sites.
>
> What I am not sure is what to return: "unknown" is safer as of now than NULL
> for sure, but really, what happened is NOT that the name was "unknown" (which
> by itself would be out-of-spec behaviour) it is more that the whole domain that
> was referred to that was invalid and NOT existent...
>
> ....mmm I suppose we are opening another can of worms here :P
Like scmi_perf_info_get() returning ERR_PTR(-EINVAL) instead of NULL,
and scmi_perf_domain_probe() never checking the return value anyway?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, May 15, 2026 at 02:00:24PM +0200, Geert Uytterhoeven wrote: > Hi Cristian, > > On Fri, 15 May 2026 at 13:46, Cristian Marussi <cristian.marussi@arm.com> wrote: > > On Fri, May 15, 2026 at 01:29:27PM +0200, Geert Uytterhoeven wrote: > > > On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote: > > > > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote: > > > > > scmi_power_name_get() does not validate the domain number passed by the > > > > > external caller, which may lead to an out-of-bounds access. > > > > > > > > Is an external caller an out of tree caller? So far as I can see this > > > > > > I meant a caller outside drivers/firmware/arm_scmi/. > > > > > > > is only called by scmi_pm_domain_probe(). > > > > > > > > scmi_pd->name = power_ops->name_get(ph, i); > > > > > > > > where i < num_domains. > > > > > > You are right. But this seems to be only API implementation in > > > drivers/firmware/arm_scmi/ that does not validate the passed domain > > > number. > > > > Yes we tend to validate protocol operations calls even if apparently > > safe from teh caller perspective...indeed I have this fixed locally > > since ages in an horrible patch, that does a lot more, and that I > > never posted :P > > > > Usually, if it is worth, we also build an internal domain get helper to > > reuse across the protocol unit...but here really there are only 2 call-sites. > > > > What I am not sure is what to return: "unknown" is safer as of now than NULL > > for sure, but really, what happened is NOT that the name was "unknown" (which > > by itself would be out-of-spec behaviour) it is more that the whole domain that > > was referred to that was invalid and NOT existent... > > > > ....mmm I suppose we are opening another can of worms here :P > > Like scmi_perf_info_get() returning ERR_PTR(-EINVAL) instead of NULL, > and scmi_perf_domain_probe() never checking the return value anyway? ...oh probably more than that...and related vendor FW that already exploits these missing checks here and there to arbitrarily skip domains and return out-of-spec non-contigous sets of domains becasue they cannot bother to implement properly the spec (or they have simply forked their codebase from an old drop and never updated it again...)...so that any kernel-side fix you made along the road carries the risk of breaking something and a string of possibly needed quirks... Cheers, Cristian
On Fri, May 15, 2026 at 01:10:56PM +0100, Cristian Marussi wrote: > On Fri, May 15, 2026 at 02:00:24PM +0200, Geert Uytterhoeven wrote: > > Hi Cristian, > > > > On Fri, 15 May 2026 at 13:46, Cristian Marussi <cristian.marussi@arm.com> wrote: > > > On Fri, May 15, 2026 at 01:29:27PM +0200, Geert Uytterhoeven wrote: > > > > On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote: > > > > > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote: > > > > > > scmi_power_name_get() does not validate the domain number passed by the > > > > > > external caller, which may lead to an out-of-bounds access. > > > > > > > > > > Is an external caller an out of tree caller? So far as I can see this > > > > > > > > I meant a caller outside drivers/firmware/arm_scmi/. > > > > > > > > > is only called by scmi_pm_domain_probe(). > > > > > > > > > > scmi_pd->name = power_ops->name_get(ph, i); > > > > > > > > > > where i < num_domains. > > > > > > > > You are right. But this seems to be only API implementation in > > > > drivers/firmware/arm_scmi/ that does not validate the passed domain > > > > number. > > > > > > Yes we tend to validate protocol operations calls even if apparently > > > safe from teh caller perspective...indeed I have this fixed locally > > > since ages in an horrible patch, that does a lot more, and that I > > > never posted :P > > > > > > Usually, if it is worth, we also build an internal domain get helper to > > > reuse across the protocol unit...but here really there are only 2 call-sites. > > > > > > What I am not sure is what to return: "unknown" is safer as of now than NULL > > > for sure, but really, what happened is NOT that the name was "unknown" (which > > > by itself would be out-of-spec behaviour) it is more that the whole domain that > > > was referred to that was invalid and NOT existent... > > > > > > ....mmm I suppose we are opening another can of worms here :P > > > > Like scmi_perf_info_get() returning ERR_PTR(-EINVAL) instead of NULL, > > and scmi_perf_domain_probe() never checking the return value anyway? > > ...oh probably more than that...and related vendor FW that already exploits > these missing checks here and there to arbitrarily skip domains and return > out-of-spec non-contigous sets of domains becasue they cannot bother to > implement properly the spec (or they have simply forked their codebase from > an old drop and never updated it again...)...so that any kernel-side fix > you made along the road carries the risk of breaking something and a string > of possibly needed quirks... Anyway, it is the safest option on the table until proper checks are in place. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Thanks, Cristian
On Tue, May 19, 2026 at 09:36:40AM +0100, Cristian Marussi wrote: > On Fri, May 15, 2026 at 01:10:56PM +0100, Cristian Marussi wrote: > > On Fri, May 15, 2026 at 02:00:24PM +0200, Geert Uytterhoeven wrote: > > > Hi Cristian, > > > > > > On Fri, 15 May 2026 at 13:46, Cristian Marussi <cristian.marussi@arm.com> wrote: > > > > On Fri, May 15, 2026 at 01:29:27PM +0200, Geert Uytterhoeven wrote: > > > > > On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote: > > > > > > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote: > > > > > > > scmi_power_name_get() does not validate the domain number passed by the > > > > > > > external caller, which may lead to an out-of-bounds access. > > > > > > > > > > > > Is an external caller an out of tree caller? So far as I can see this > > > > > > > > > > I meant a caller outside drivers/firmware/arm_scmi/. > > > > > > > > > > > is only called by scmi_pm_domain_probe(). > > > > > > > > > > > > scmi_pd->name = power_ops->name_get(ph, i); > > > > > > > > > > > > where i < num_domains. > > > > > > > > > > You are right. But this seems to be only API implementation in > > > > > drivers/firmware/arm_scmi/ that does not validate the passed domain > > > > > number. > > > > > > > > Yes we tend to validate protocol operations calls even if apparently > > > > safe from teh caller perspective...indeed I have this fixed locally > > > > since ages in an horrible patch, that does a lot more, and that I > > > > never posted :P > > > > > > > > Usually, if it is worth, we also build an internal domain get helper to > > > > reuse across the protocol unit...but here really there are only 2 call-sites. > > > > > > > > What I am not sure is what to return: "unknown" is safer as of now than NULL > > > > for sure, but really, what happened is NOT that the name was "unknown" (which > > > > by itself would be out-of-spec behaviour) it is more that the whole domain that > > > > was referred to that was invalid and NOT existent... > > > > > > > > ....mmm I suppose we are opening another can of worms here :P > > > > > > Like scmi_perf_info_get() returning ERR_PTR(-EINVAL) instead of NULL, > > > and scmi_perf_domain_probe() never checking the return value anyway? > > > > ...oh probably more than that...and related vendor FW that already exploits > > these missing checks here and there to arbitrarily skip domains and return > > out-of-spec non-contigous sets of domains becasue they cannot bother to > > implement properly the spec (or they have simply forked their codebase from > > an old drop and never updated it again...)...so that any kernel-side fix > > you made along the road carries the risk of breaking something and a string > > of possibly needed quirks... > > Anyway, it is the safest option on the table until proper checks are in place. > > Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> If it has a description like this then it's absolutely going to get a CVE assigned. We're used to hundreds of CVEs and all but I really feel like this is a bad habit. regards, dan carpenter
On Tue, May 19, 2026 at 11:46:55AM +0300, Dan Carpenter wrote: > On Tue, May 19, 2026 at 09:36:40AM +0100, Cristian Marussi wrote: > > On Fri, May 15, 2026 at 01:10:56PM +0100, Cristian Marussi wrote: > > > On Fri, May 15, 2026 at 02:00:24PM +0200, Geert Uytterhoeven wrote: > > > > Hi Cristian, > > > > > > > > On Fri, 15 May 2026 at 13:46, Cristian Marussi <cristian.marussi@arm.com> wrote: > > > > > On Fri, May 15, 2026 at 01:29:27PM +0200, Geert Uytterhoeven wrote: > > > > > > On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote: > > > > > > > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote: > > > > > > > > scmi_power_name_get() does not validate the domain number passed by the > > > > > > > > external caller, which may lead to an out-of-bounds access. > > > > > > > > > > > > > > Is an external caller an out of tree caller? So far as I can see this > > > > > > > > > > > > I meant a caller outside drivers/firmware/arm_scmi/. > > > > > > > > > > > > > is only called by scmi_pm_domain_probe(). > > > > > > > > > > > > > > scmi_pd->name = power_ops->name_get(ph, i); > > > > > > > > > > > > > > where i < num_domains. > > > > > > > > > > > > You are right. But this seems to be only API implementation in > > > > > > drivers/firmware/arm_scmi/ that does not validate the passed domain > > > > > > number. > > > > > > > > > > Yes we tend to validate protocol operations calls even if apparently > > > > > safe from teh caller perspective...indeed I have this fixed locally > > > > > since ages in an horrible patch, that does a lot more, and that I > > > > > never posted :P > > > > > > > > > > Usually, if it is worth, we also build an internal domain get helper to > > > > > reuse across the protocol unit...but here really there are only 2 call-sites. > > > > > > > > > > What I am not sure is what to return: "unknown" is safer as of now than NULL > > > > > for sure, but really, what happened is NOT that the name was "unknown" (which > > > > > by itself would be out-of-spec behaviour) it is more that the whole domain that > > > > > was referred to that was invalid and NOT existent... > > > > > > > > > > ....mmm I suppose we are opening another can of worms here :P > > > > > > > > Like scmi_perf_info_get() returning ERR_PTR(-EINVAL) instead of NULL, > > > > and scmi_perf_domain_probe() never checking the return value anyway? > > > > > > ...oh probably more than that...and related vendor FW that already exploits > > > these missing checks here and there to arbitrarily skip domains and return > > > out-of-spec non-contigous sets of domains becasue they cannot bother to > > > implement properly the spec (or they have simply forked their codebase from > > > an old drop and never updated it again...)...so that any kernel-side fix > > > you made along the road carries the risk of breaking something and a string > > > of possibly needed quirks... > > > > Anyway, it is the safest option on the table until proper checks are in place. > > > > Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> > > If it has a description like this then it's absolutely going to get a CVE > assigned. We're used to hundreds of CVEs and all but I really feel like > this is a bad habit. Indeed, I think already happened to get a CVE on this internal improved checks despite the fix was more a defensive thing since it had no chance to be exposed by the current code. I could be wrong but I think that this is one of the reason I started using (and maybe abusing) for similar patches the "Harden protocol...." commmit-msg because it really does not qualify as Fixes for backporting as specified in [1] [1]: https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst ...so at the end probably worth to drop Fixes as you said earlier... Thanks, Cristian
On Fri, May 15, 2026 at 01:29:27PM +0200, Geert Uytterhoeven wrote: > Hi Dan, > > On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote: > > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote: > > > scmi_power_name_get() does not validate the domain number passed by the > > > external caller, which may lead to an out-of-bounds access. > > > > Is an external caller an out of tree caller? So far as I can see this > > I meant a caller outside drivers/firmware/arm_scmi/. > > > is only called by scmi_pm_domain_probe(). > > > > scmi_pd->name = power_ops->name_get(ph, i); > > > > where i < num_domains. > > You are right. But this seems to be only API implementation in > drivers/firmware/arm_scmi/ that does not validate the passed domain > number. I don't have a problem with the patch but I don't think it should have a Fixes tag. regards, dan carpenter
© 2016 - 2026 Red Hat, Inc.