linux-kernel - Re: [PATCH] media: rcar-vin: fix a potential NULL pointer dereference

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190309110217.GA5281@bigcity.dyn.berto.se>
Date:   Sat, 9 Mar 2019 12:02:17 +0100
From:   Niklas Söderlund 
        <niklas.soderlund@...natech.se>
To:     Kangjie Lu <kjlu@....edu>
Cc:     pakki001@....edu, Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: rcar-vin: fix a potential NULL pointer dereference

Hi Kangjie,

Thanks for your patch.

On 2019-03-09 01:05:27 -0600, Kangjie Lu wrote:
> In case of_match_node cannot find a match, the fix returns
> -EINVAL to avoid NULL pointer dereference.
> 
> Signed-off-by: Kangjie Lu <kjlu@....edu>
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
> index f0719ce24b97..a058e2023ca8 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -266,6 +266,8 @@ static int rvin_group_init(struct rvin_group *group, struct rvin_dev *vin)
>  
>  	match = of_match_node(vin->dev->driver->of_match_table,
>  			      vin->dev->of_node);
> +	if (unlikely(!match))
> +		return -EINVAL;

I don't think this is needed. The driver depends on selects OF and if we 
get this far we it is because we had a match already. The reason to call 
of_match_node() here is simply to retrieve which of the possible 
compatible strings was matched.

Am I missing something? What scenario do you see where this can fail?

>  
>  	strscpy(mdev->driver_name, KBUILD_MODNAME, sizeof(mdev->driver_name));
>  	strscpy(mdev->model, match->compatible, sizeof(mdev->model));
> -- 
> 2.17.1
> 

-- 
Regards,
Niklas Söderlund