Since commit b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier
registration for unsupported events") the call chains leading to the helper
__scmi_event_handler_get_ops expect an ERR_PTR to be returned on failure to
get an handler for the requested event key, while the current helper can
still return a NULL when no handler could be found or created.

Fix by forcing an ERR_PTR return value when the handler reference is NULL.

Fixes: b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier registration for unsupported events")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
 drivers/firmware/arm_scmi/notify.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c
index 9168794adae4..40ec184eedae 100644
--- a/drivers/firmware/arm_scmi/notify.c
+++ b/drivers/firmware/arm_scmi/notify.c
@@ -1066,7 +1066,7 @@ static int scmi_register_event_handler(struct scmi_notify_instance *ni,
  * since at creation time we usually want to have all setup and ready before
  * events really start flowing.
  *
- * Return: A properly refcounted handler on Success, NULL on Failure
+ * Return: A properly refcounted handler on Success, ERR_PTR on Failure
  */
 static inline struct scmi_event_handler *
 __scmi_event_handler_get_ops(struct scmi_notify_instance *ni,
@@ -1113,7 +1113,7 @@ __scmi_event_handler_get_ops(struct scmi_notify_instance *ni,
 	}
 	mutex_unlock(&ni->pending_mtx);
 
-	return hndl;
+	return hndl ?: ERR_PTR(-ENODEV);
 }
 
 static struct scmi_event_handler *
-- 
2.53.0

On Thu, 05 Mar 2026 13:10:11 +0000, Cristian Marussi wrote:
> Since commit b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier
> registration for unsupported events") the call chains leading to the helper
> __scmi_event_handler_get_ops expect an ERR_PTR to be returned on failure to
> get an handler for the requested event key, while the current helper can
> still return a NULL when no handler could be found or created.
> 
> Fix by forcing an ERR_PTR return value when the handler reference is NULL.
> 
> [...]

Applied to sudeep.holla/linux (for-next/scmi/fixes), thanks!

[1/1] firmware: arm_scmi: Fix NULL dereference on notify error path
      https://git.kernel.org/sudeep.holla/c/555317d61001
--
Regards,
Sudeep

On Thu, Mar 05, 2026 at 01:10:11PM +0000, Cristian Marussi wrote:
> Since commit b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier
> registration for unsupported events") the call chains leading to the helper
> __scmi_event_handler_get_ops expect an ERR_PTR to be returned on failure to
> get an handler for the requested event key, while the current helper can
> still return a NULL when no handler could be found or created.
> 
> Fix by forcing an ERR_PTR return value when the handler reference is NULL.
> 
> Fixes: b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier registration for unsupported events")
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---

Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>

I feel a bit bad about this.  I saw this as a Smatch warning last August
but I somehow marked it as a false positive.  :/

regards,
dan carpenter

On Thu, Mar 05, 2026 at 06:09:47PM +0300, Dan Carpenter wrote:
> On Thu, Mar 05, 2026 at 01:10:11PM +0000, Cristian Marussi wrote:
> > Since commit b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier
> > registration for unsupported events") the call chains leading to the helper
> > __scmi_event_handler_get_ops expect an ERR_PTR to be returned on failure to
> > get an handler for the requested event key, while the current helper can
> > still return a NULL when no handler could be found or created.
> > 
> > Fix by forcing an ERR_PTR return value when the handler reference is NULL.
> > 
> > Fixes: b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier registration for unsupported events")
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---

Hi Dan,

> 
> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>

Thanks for you review.

> 
> I feel a bit bad about this.  I saw this as a Smatch warning last August
> but I somehow marked it as a false positive.  :/

:P

...it was tricky because the code is bit convoluted...
...indeed I posted this as a quick easy backportable fix BUT I am gonna
post soon a full rework on top of this around that function and the
whole SCMI notification core code that makes use of cleanup handlers
since they greatly simplify some of the mutexes hell around this
stuff...

Thanks,
Cristian