Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1469372 > unrolled thread
| Started by | LABBE Corentin <clabbe.montjoie@gmail.com> |
|---|---|
| First post | 2016-08-24 14:10 +0200 |
| Last post | 2016-08-24 15:30 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
[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
| From | LABBE Corentin <clabbe.montjoie@gmail.com> |
|---|---|
| Date | 2016-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]
| From | Thierry Reding <thierry.reding@gmail.com> |
|---|---|
| Date | 2016-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