From: Cristian Marussi <[email protected]>
[ Upstream commit e9076ffbcaed5da6c182b144ef9f6e24554af268 ]
Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.
Add an internal consistency check before any such domains descriptors
accesses.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Cristian Marussi <[email protected]>
Signed-off-by: Sudeep Holla <[email protected]>
Signed-off-by: Dominique Martinet <[email protected]>
---
This is the backport I promised for CVE-2022-48655[1]
[1] https://lkml.kernel.org/r/[email protected]
The 'pi' variable declaration context just changed a bit
(handle->reset_priv -> ph->get_priv(ph)) but the patch is
otherwise fine as is.
(I've also checked that num_domains is properly initialized at module
init time and this part of the code hasn't changed until 5.15, so it
should be safe to use this previously unused field)
This same patch applies cleanly to both 5.4.275 and 5.10.216.
Thanks!
drivers/firmware/arm_scmi/reset.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_scmi/reset.c b/drivers/firmware/arm_scmi/reset.c
index a981a22cfe89..b8388a3b9c06 100644
--- a/drivers/firmware/arm_scmi/reset.c
+++ b/drivers/firmware/arm_scmi/reset.c
@@ -149,8 +149,12 @@ static int scmi_domain_reset(const struct scmi_handle *handle, u32 domain,
struct scmi_xfer *t;
struct scmi_msg_reset_domain_reset *dom;
struct scmi_reset_info *pi = handle->reset_priv;
- struct reset_dom_info *rdom = pi->dom_info + domain;
+ struct reset_dom_info *rdom;
+ if (domain >= pi->num_domains)
+ return -EINVAL;
+
+ rdom = pi->dom_info + domain;
if (rdom->async_reset)
flags |= ASYNCHRONOUS_RESET;
--
2.39.2
On Mon, May 13, 2024 at 09:38:37AM +0900, Dominique Martinet wrote:
> From: Cristian Marussi <[email protected]>
>
> [ Upstream commit e9076ffbcaed5da6c182b144ef9f6e24554af268 ]
>
> Accessing reset domains descriptors by the index upon the SCMI drivers
> requests through the SCMI reset operations interface can potentially
> lead to out-of-bound violations if the SCMI driver misbehave.
>
> Add an internal consistency check before any such domains descriptors
> accesses.
>
> Link: https://lore.kernel.org/r/[email protected]
> Signed-off-by: Cristian Marussi <[email protected]>
> Signed-off-by: Sudeep Holla <[email protected]>
> Signed-off-by: Dominique Martinet <[email protected]>
> ---
> This is the backport I promised for CVE-2022-48655[1]
> [1] https://lkml.kernel.org/r/[email protected]
>
The backport looks good and thanks for doing that. Sometimes since we
know all the users are in the kernel, we tend to ignore the facts that
they need to be backport as this was considered as theoretical issue when
we pushed the fix. We try to keep that in mind and add fixes tag more
carefully in the future. Thanks for your effort and bring this to our
attention.
--
Regards,
Sudeep
On Mon, May 13, 2024 at 10:22:21AM +0100, Sudeep Holla wrote:
> On Mon, May 13, 2024 at 09:38:37AM +0900, Dominique Martinet wrote:
> > From: Cristian Marussi <[email protected]>
> >
> > [ Upstream commit e9076ffbcaed5da6c182b144ef9f6e24554af268 ]
> >
> > Accessing reset domains descriptors by the index upon the SCMI drivers
> > requests through the SCMI reset operations interface can potentially
> > lead to out-of-bound violations if the SCMI driver misbehave.
> >
> > Add an internal consistency check before any such domains descriptors
> > accesses.
> >
> > Link: https://lore.kernel.org/r/[email protected]
> > Signed-off-by: Cristian Marussi <[email protected]>
> > Signed-off-by: Sudeep Holla <[email protected]>
> > Signed-off-by: Dominique Martinet <[email protected]>
> > ---
> > This is the backport I promised for CVE-2022-48655[1]
> > [1] https://lkml.kernel.org/r/[email protected]
> >
>
> The backport looks good and thanks for doing that. Sometimes since we
> know all the users are in the kernel, we tend to ignore the facts that
> they need to be backport as this was considered as theoretical issue when
> we pushed the fix. We try to keep that in mind and add fixes tag more
> carefully in the future. Thanks for your effort and bring this to our
> attention.
Now queued up, thanks
greg k-h