All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gustavo A. R. Silva" <garsilva-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org>
To: Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
	linux-arm-msm
	<linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	freedreno
	<freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH] drm/msm/adreno/a5xx_debugfs: fix potential NULL pointer dereference
Date: Sat, 03 Feb 2018 06:22:28 -0600	[thread overview]
Message-ID: <20180203062228.Horde.Yi_1isNJ5NW9KaWlA9DyQsP@gator4166.hostgator.com> (raw)
In-Reply-To: <CAF6AEGuKHknW3o4tfe95E7RLLk7OQGTFh=HDtijPDQyp3b+B6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>


Quoting Rob Clark <robdclark@gmail.com>:

> On Fri, Feb 2, 2018 at 11:30 AM, Jordan Crouse  
> <jcrouse@codeaurora.org> wrote:
>> On Fri, Feb 02, 2018 at 06:32:23AM -0600, Gustavo A. R. Silva wrote:
>>> _minor_ is being dereferenced before it is null checked, hence there
>>> is a potential null pointer dereference. Fix this by moving the pointer
>>> dereference after _minor_ has been null checked.
>>>
>>> Fixes: 024ad8df763f ("drm/msm: add a5xx specific debugfs")
>>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>>> ---
>>>
>>> I wonder if a better solution for this would be to WARN_ON in case _minor_
>>> happens to be NULL and return -EINVAL, instead of just returning zero.
>>>
>>> Something like:
>>>
>>> struct drm_device *dev;
>>>
>>> if (WARN_ON(!minor)
>>>       return -EINVAL;
>>>
>>> dev = minor->dev;
>>>
>>> What do you think?
>>
>> In my opinion everything in debugfs is optional. I'm not sure if it is even
>> possible for dev->primary, dev->render or dev->control to be NULL  
>> from the DRM
>> core but if so I think the failure should be silent.
>>
>
> Don't have code in front of me atm, but I think this is one of those
> things you can hit both before and after we have the minor, depending
> on whether filesystem and fw are present when the driver loads or
> not.. so I don't think it should be a WARN_ON().
>

I get it. Then in this case this patch should work just fine.

Thank you both Jordan and Rob for the feedback.
--
Gustavo

> BR,
> -R
>
>
>> Jordan
>>>
>>>  drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c  
>>> b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
>>> index 6b27941..059ec7d 100644
>>> --- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
>>> +++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
>>> @@ -159,13 +159,15 @@ DEFINE_SIMPLE_ATTRIBUTE(reset_fops, NULL,  
>>> reset_set, "%llx\n");
>>>
>>>  int a5xx_debugfs_init(struct msm_gpu *gpu, struct drm_minor *minor)
>>>  {
>>> -     struct drm_device *dev = minor->dev;
>>> +     struct drm_device *dev;
>>>       struct dentry *ent;
>>>       int ret;
>>>
>>>       if (!minor)
>>>               return 0;
>>>
>>> +     dev = minor->dev;
>>> +
>>>       ret = drm_debugfs_create_files(a5xx_debugfs_list,
>>>                       ARRAY_SIZE(a5xx_debugfs_list),
>>>                       minor->debugfs_root, minor);
>>> --
>>> 2.7.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> --
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project






_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

WARNING: multiple messages have this Message-ID (diff)
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
To: Rob Clark <robdclark@gmail.com>
Cc: David Airlie <airlied@linux.ie>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	freedreno <freedreno@lists.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/msm/adreno/a5xx_debugfs: fix potential NULL pointer dereference
Date: Sat, 03 Feb 2018 06:22:28 -0600	[thread overview]
Message-ID: <20180203062228.Horde.Yi_1isNJ5NW9KaWlA9DyQsP@gator4166.hostgator.com> (raw)
In-Reply-To: <CAF6AEGuKHknW3o4tfe95E7RLLk7OQGTFh=HDtijPDQyp3b+B6Q@mail.gmail.com>


Quoting Rob Clark <robdclark@gmail.com>:

> On Fri, Feb 2, 2018 at 11:30 AM, Jordan Crouse  
> <jcrouse@codeaurora.org> wrote:
>> On Fri, Feb 02, 2018 at 06:32:23AM -0600, Gustavo A. R. Silva wrote:
>>> _minor_ is being dereferenced before it is null checked, hence there
>>> is a potential null pointer dereference. Fix this by moving the pointer
>>> dereference after _minor_ has been null checked.
>>>
>>> Fixes: 024ad8df763f ("drm/msm: add a5xx specific debugfs")
>>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>>> ---
>>>
>>> I wonder if a better solution for this would be to WARN_ON in case _minor_
>>> happens to be NULL and return -EINVAL, instead of just returning zero.
>>>
>>> Something like:
>>>
>>> struct drm_device *dev;
>>>
>>> if (WARN_ON(!minor)
>>>       return -EINVAL;
>>>
>>> dev = minor->dev;
>>>
>>> What do you think?
>>
>> In my opinion everything in debugfs is optional. I'm not sure if it is even
>> possible for dev->primary, dev->render or dev->control to be NULL  
>> from the DRM
>> core but if so I think the failure should be silent.
>>
>
> Don't have code in front of me atm, but I think this is one of those
> things you can hit both before and after we have the minor, depending
> on whether filesystem and fw are present when the driver loads or
> not.. so I don't think it should be a WARN_ON().
>

I get it. Then in this case this patch should work just fine.

Thank you both Jordan and Rob for the feedback.
--
Gustavo

> BR,
> -R
>
>
>> Jordan
>>>
>>>  drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c  
>>> b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
>>> index 6b27941..059ec7d 100644
>>> --- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
>>> +++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
>>> @@ -159,13 +159,15 @@ DEFINE_SIMPLE_ATTRIBUTE(reset_fops, NULL,  
>>> reset_set, "%llx\n");
>>>
>>>  int a5xx_debugfs_init(struct msm_gpu *gpu, struct drm_minor *minor)
>>>  {
>>> -     struct drm_device *dev = minor->dev;
>>> +     struct drm_device *dev;
>>>       struct dentry *ent;
>>>       int ret;
>>>
>>>       if (!minor)
>>>               return 0;
>>>
>>> +     dev = minor->dev;
>>> +
>>>       ret = drm_debugfs_create_files(a5xx_debugfs_list,
>>>                       ARRAY_SIZE(a5xx_debugfs_list),
>>>                       minor->debugfs_root, minor);
>>> --
>>> 2.7.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> --
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project

  parent reply	other threads:[~2018-02-03 12:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-02 12:32 [PATCH] drm/msm/adreno/a5xx_debugfs: fix potential NULL pointer dereference Gustavo A. R. Silva
2018-02-02 16:30 ` Jordan Crouse
2018-02-02 16:30   ` Jordan Crouse
     [not found]   ` <20180202163006.GA878-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>
2018-02-02 19:04     ` Rob Clark
2018-02-02 19:04       ` Rob Clark
     [not found]       ` <CAF6AEGuKHknW3o4tfe95E7RLLk7OQGTFh=HDtijPDQyp3b+B6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-03 12:22         ` Gustavo A. R. Silva [this message]
2018-02-03 12:22           ` Gustavo A. R. Silva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180203062228.Horde.Yi_1isNJ5NW9KaWlA9DyQsP@gator4166.hostgator.com \
    --to=garsilva-l1vi/lxtdts+va1gwouvdg@public.gmane.org \
    --cc=airlied-cv59FeDIM0c@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.