[PATCH] drm/mediatek: Initialize pointer before use to avoid undefiend behaviour

[PATCH] drm/mediatek: Initialize pointer before use to avoid undefiend behaviour

[Karan Sanghavi]

Initialize the pointer with NULL as mtk_drm_of_get_ddp_ep_cid
function might return before assigning value to next pointer
but yet further dereference to next can lead to some undefined
behavior as it may point to some invalid location.

Fixes: 4c932840db1d ("drm/mediatek: Implement OF graphs support for display paths")
Signed-off-by: Karan Sanghavi <karansanghvi98@gmail.com>
---
Coverity Message:
CID 1601557: (#1 of 1): Uninitialized pointer read (UNINIT)
3. uninit_use: Using uninitialized value next.

Coverity Link:
https://scan7.scan.coverity.com/#/project-view/10043/11354?selectedIssue=1601557
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 9a8ef8558da9..bc06c664e80f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -900,7 +900,7 @@ static int mtk_drm_of_ddp_path_build_one(struct device *dev, enum mtk_crtc_path
 					 const unsigned int **out_path,
 					 unsigned int *out_path_len)
 {
-	struct device_node *next, *prev, *vdo = dev->parent->of_node;
+	struct device_node *next = NULL, *prev, *vdo = dev->parent->of_node;
 	unsigned int temp_path[DDP_COMPONENT_DRM_ID_MAX] = { 0 };
 	unsigned int *final_ddp_path;
 	unsigned short int idx = 0;

---
base-commit: 6d59cab07b8d74d0f0422b750038123334f6ecc2
change-id: 20241111-uninitializedpointer1601557-9803b725b6bd

Best regards,
-- 
Karan Sanghavi <karansanghvi98@gmail.com>

Re: [PATCH] drm/mediatek: Initialize pointer before use to avoid undefiend behaviour

[CK Hu (胡俊光)]

Hi, Karan:

On Mon, 2024-11-11 at 18:14 +0000, Karan Sanghavi wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
> 
> 
> Initialize the pointer with NULL as mtk_drm_of_get_ddp_ep_cid
> function might return before assigning value to next pointer
> but yet further dereference to next can lead to some undefined
> behavior as it may point to some invalid location.

Reviewed-by: CK Hu <ck.hu@mediatek.com>

> 
> Fixes: 4c932840db1d ("drm/mediatek: Implement OF graphs support for display paths")
> Signed-off-by: Karan Sanghavi <karansanghvi98@gmail.com>
> ---
> Coverity Message:
> CID 1601557: (#1 of 1): Uninitialized pointer read (UNINIT)
> 3. uninit_use: Using uninitialized value next.
> 
> Coverity Link:
> https://urldefense.com/v3/__https://scan7.scan.coverity.com/*/project-view/10043/11354?selectedIssue=1601557__;Iw!!CTRNKA9wMg0ARbw!hoVl7EQYL36rg2pnVInf2AL6m6mTbIeAsFyOuAlfdlSRMyvrR_vU4CAuIv1h5NnvGEUwMsEY8qxDQ8Mgkc5JyTo$
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 9a8ef8558da9..bc06c664e80f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -900,7 +900,7 @@ static int mtk_drm_of_ddp_path_build_one(struct device *dev, enum mtk_crtc_path
>                                          const unsigned int **out_path,
>                                          unsigned int *out_path_len)
>  {
> -       struct device_node *next, *prev, *vdo = dev->parent->of_node;
> +       struct device_node *next = NULL, *prev, *vdo = dev->parent->of_node;
>         unsigned int temp_path[DDP_COMPONENT_DRM_ID_MAX] = { 0 };
>         unsigned int *final_ddp_path;
>         unsigned short int idx = 0;
> 
> ---
> base-commit: 6d59cab07b8d74d0f0422b750038123334f6ecc2
> change-id: 20241111-uninitializedpointer1601557-9803b725b6bd
> 
> Best regards,
> --
> Karan Sanghavi <karansanghvi98@gmail.com>
> 

Re: [PATCH] drm/mediatek: Initialize pointer before use to avoid undefiend behaviour

[Markus Elfring]

> Initialize the pointer with NULL as mtk_drm_of_get_ddp_ep_cid
> function might return before assigning value to next pointer
> but yet further dereference to next can lead to some undefined
> behavior as it may point to some invalid location.

* You may occasionally put more than 62 characters into text lines
  of such a change description.

* Please avoid a typo the summary phrase.


…
> ---
> Coverity Message:
> CID 1601557: (#1 of 1): Uninitialized pointer read (UNINIT)
> 3. uninit_use: Using uninitialized value next.

May such information become a part for the final change description?

Regards,
Markus

Re: [PATCH] drm/mediatek: Initialize pointer before use to avoid undefiend behaviour

[Karan Sanghavi]

On Tue, Dec 24, 2024 at 05:09:54PM +0100, Markus Elfring wrote:
> > Initialize the pointer with NULL as mtk_drm_of_get_ddp_ep_cid
> > function might return before assigning value to next pointer
> > but yet further dereference to next can lead to some undefined
> > behavior as it may point to some invalid location.
> 
> * You may occasionally put more than 62 characters into text lines
>   of such a change description.
> 
> * Please avoid a typo the summary phrase.
> 
yes sure. will keep that in mind for hte next patch. 
> 
> …
> > ---
> > Coverity Message:
> > CID 1601557: (#1 of 1): Uninitialized pointer read (UNINIT)
> > 3. uninit_use: Using uninitialized value next.
> 
> May such information become a part for the final change description?
>
Ofcourse, it shouldn't be the part of the change description. Thus i
have added them after the '---' due to which it wouldn't be the part of
the commit log (that's my uderstanding correct me if i am wrong). If it
still adds in the commit log do let me know as it hasn't been added for
other patches. 

it is just for the reference to understand more about what the error message
is generated by coverity scan.

Thank you,
karan.
> Regards,
> Markus

Re: drm/mediatek: Initialize pointer before use to avoid undefiend behaviour

[Markus Elfring]

>> …
>>> ---
>>> Coverity Message:
>>> CID 1601557: (#1 of 1): Uninitialized pointer read (UNINIT)
>>> 3. uninit_use: Using uninitialized value next.
>>
>> May such information become a part for the final change description?
>>
> Ofcourse, it shouldn't be the part of the change description.

I suggest to reconsider this view once more.


> it is just for the reference to understand more about what the error message
> is generated by coverity scan.
Please take another look at possibilities how other contributors indicated
that some change opportunities were pointed out by advanced source code
analysis tools.

Regards,
Markus