| Message ID | 20231025145829.11603-1-quic_mdtipton@quicinc.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Headers | show |
| Series | interconnect: Treat xlate() returning NULL node as an error | expand |
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c index dfab160ca529..50bac2d79d9b 100644 --- a/drivers/interconnect/core.c +++ b/drivers/interconnect/core.c @@ -395,6 +395,9 @@ struct icc_node_data *of_icc_get_from_provider(struct of_phandle_args *spec) } mutex_unlock(&icc_lock); + if (!node) + return ERR_PTR(-EINVAL); + if (IS_ERR(node)) return ERR_CAST(node);
Currently, if provider->xlate() or provider->xlate_extended() "successfully" return a NULL node, then of_icc_get_from_provider() won't consider that an error and will successfully return the NULL node. This bypasses error handling in of_icc_get_by_index() and leads to NULL dereferences in path_find(). This could be avoided by ensuring provider callbacks always return an error for NULL nodes, but it's better to explicitly protect against this in the common framework. Fixes: 87e3031b6fbd ("interconnect: Allow endpoints translation via DT") Signed-off-by: Mike Tipton <quic_mdtipton@quicinc.com> --- I'm not specifically aware of any upstream cases of this happening, but we did hit this downstream. And it's hard to ensure this can never happen upstream, since it's hard to ensure that none of the qcom_icc_desc::nodes arrays have zero holes in them, for instance. drivers/interconnect/core.c | 3 +++ 1 file changed, 3 insertions(+)