Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1469372 > unrolled thread

[PATCH v3] pwm: sun4i: fix a possible NULL dereference

Started byLABBE Corentin <clabbe.montjoie@gmail.com>
First post2016-08-24 14:10 +0200
Last post2016-08-24 15:30 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v3] pwm: sun4i: fix a possible NULL dereference LABBE Corentin <clabbe.montjoie@gmail.com> - 2016-08-24 14:10 +0200
    Re: [PATCH v3] pwm: sun4i: fix a possible NULL dereference Thierry Reding <thierry.reding@gmail.com> - 2016-08-24 15:30 +0200

#1469372 — [PATCH v3] pwm: sun4i: fix a possible NULL dereference

FromLABBE Corentin <clabbe.montjoie@gmail.com>
Date2016-08-24 14:10 +0200
Subject[PATCH v3] pwm: sun4i: fix a possible NULL dereference
Message-ID<s9Fah-22U-17@gated-at.bofh.it>
of_match_device could return NULL, and so cause a NULL pointer
dereference later.

For fixing this problem, we use of_device_get_match_data(), this will
simplify the code a little by using a standard function for
getting the match data.

Testing the return value of of_device_get_match_data is also necessary
for avoiding a second NULL deref on pwm->data.

Reported-by: coverity (CID 1324139)
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
Changes since v2:
 - Add a test on pwm->data for avoiding a second NULL deref.
Changes since v1:
 - Use of_device_get_match_data()

 drivers/pwm/pwm-sun4i.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 03a99a5..fb76c55 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -309,9 +309,6 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
 	struct resource *res;
 	u32 val;
 	int i, ret;
-	const struct of_device_id *match;
-
-	match = of_match_device(sun4i_pwm_dt_ids, &pdev->dev);
 
 	pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
 	if (!pwm)
@@ -326,7 +323,9 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
 	if (IS_ERR(pwm->clk))
 		return PTR_ERR(pwm->clk);
 
-	pwm->data = match->data;
+	pwm->data = of_device_get_match_data(&pdev->dev);
+	if (!pwm->data)
+		return -EINVAL;
 	pwm->chip.dev = &pdev->dev;
 	pwm->chip.ops = &sun4i_pwm_ops;
 	pwm->chip.base = -1;
-- 
2.7.3

[toc] | [next] | [standalone]


#1469434

FromThierry Reding <thierry.reding@gmail.com>
Date2016-08-24 15:30 +0200
Message-ID<s9GpI-2LQ-39@gated-at.bofh.it>
In reply to#1469372

[Multipart message — attachments visible in raw view] — view raw

On Wed, Aug 24, 2016 at 01:43:58PM +0200, LABBE Corentin wrote:
> of_match_device could return NULL, and so cause a NULL pointer
> dereference later.
> 
> For fixing this problem, we use of_device_get_match_data(), this will
> simplify the code a little by using a standard function for
> getting the match data.
> 
> Testing the return value of of_device_get_match_data is also necessary
> for avoiding a second NULL deref on pwm->data.
> 
> Reported-by: coverity (CID 1324139)
> Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
> ---
> Changes since v2:
>  - Add a test on pwm->data for avoiding a second NULL deref.
> Changes since v1:
>  - Use of_device_get_match_data()
> 
>  drivers/pwm/pwm-sun4i.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 03a99a5..fb76c55 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -309,9 +309,6 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>  	struct resource *res;
>  	u32 val;
>  	int i, ret;
> -	const struct of_device_id *match;
> -
> -	match = of_match_device(sun4i_pwm_dt_ids, &pdev->dev);
>  
>  	pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
>  	if (!pwm)
> @@ -326,7 +323,9 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>  	if (IS_ERR(pwm->clk))
>  		return PTR_ERR(pwm->clk);
>  
> -	pwm->data = match->data;
> +	pwm->data = of_device_get_match_data(&pdev->dev);
> +	if (!pwm->data)
> +		return -EINVAL;

I don't see how this would ever be NULL. You'd have to add an entry to
the table that has a NULL data field, which is very unlikely to happen.
If you really want to check for this, which I think isn't necessary,
please wrap this in a WARN_ON() or something to make more noise when
this completely unexpected case happens.

Thierry

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web