2017-04-06 19:32:24

by Helen Koike

[permalink] [raw]
Subject: [PATCH] [media] media-entity: only call dev_dbg_obj if mdev is not NULL

Fix kernel Oops NULL pointer deference
Call dev_dbg_obj only after checking if gobj->mdev is not NULL

Signed-off-by: Helen Koike <[email protected]>
---
drivers/media/media-entity.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 5640ca2..bc44193 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -199,12 +199,12 @@ void media_gobj_create(struct media_device *mdev,

void media_gobj_destroy(struct media_gobj *gobj)
{
- dev_dbg_obj(__func__, gobj);
-
/* Do nothing if the object is not linked. */
if (gobj->mdev == NULL)
return;

+ dev_dbg_obj(__func__, gobj);
+
gobj->mdev->topology_version++;

/* Remove the object from mdev list */
--
2.7.4


2017-04-07 07:41:00

by Sakari Ailus

[permalink] [raw]
Subject: Re: [PATCH] [media] media-entity: only call dev_dbg_obj if mdev is not NULL

Hi Helen,

On Thu, Apr 06, 2017 at 04:32:00PM -0300, Helen Koike wrote:
> Fix kernel Oops NULL pointer deference
> Call dev_dbg_obj only after checking if gobj->mdev is not NULL
>
> Signed-off-by: Helen Koike <[email protected]>
> ---
> drivers/media/media-entity.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index 5640ca2..bc44193 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -199,12 +199,12 @@ void media_gobj_create(struct media_device *mdev,
>
> void media_gobj_destroy(struct media_gobj *gobj)
> {
> - dev_dbg_obj(__func__, gobj);
> -
> /* Do nothing if the object is not linked. */
> if (gobj->mdev == NULL)
> return;
>
> + dev_dbg_obj(__func__, gobj);
> +
> gobj->mdev->topology_version++;
>
> /* Remove the object from mdev list */

Where is media_gobj_destroy() called with an object with NULL mdev?

I do not object to the change, but would like to know because I don't think
it's supposed to happen.

There are issues though, until the patches fixing object referencing are
finished and merged. Unfortunately I haven't been able to work on those
recently, will pick them up again soon...

--
Kind regards,

Sakari Ailus
e-mail: [email protected] XMPP: [email protected]

2017-04-07 14:36:47

by Helen Koike

[permalink] [raw]
Subject: Re: [PATCH] [media] media-entity: only call dev_dbg_obj if mdev is not NULL

Hi Sakari,

On 2017-04-07 04:40 AM, Sakari Ailus wrote:
> Hi Helen,
>
> On Thu, Apr 06, 2017 at 04:32:00PM -0300, Helen Koike wrote:
>> Fix kernel Oops NULL pointer deference
>> Call dev_dbg_obj only after checking if gobj->mdev is not NULL
>>
>> Signed-off-by: Helen Koike <[email protected]>
>> ---
>> drivers/media/media-entity.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
>> index 5640ca2..bc44193 100644
>> --- a/drivers/media/media-entity.c
>> +++ b/drivers/media/media-entity.c
>> @@ -199,12 +199,12 @@ void media_gobj_create(struct media_device *mdev,
>>
>> void media_gobj_destroy(struct media_gobj *gobj)
>> {
>> - dev_dbg_obj(__func__, gobj);
>> -
>> /* Do nothing if the object is not linked. */
>> if (gobj->mdev == NULL)
>> return;
>>
>> + dev_dbg_obj(__func__, gobj);
>> +
>> gobj->mdev->topology_version++;
>>
>> /* Remove the object from mdev list */
>
> Where is media_gobj_destroy() called with an object with NULL mdev?
>
> I do not object to the change, but would like to know because I don't think
> it's supposed to happen.


This happens when media_device_unregister(mdev) is called before
unregistering the subdevices v4l2_device_unregister_subdev(sd) (which
should be possible).

v4l2_device_unregister_subdev(sd) ends up calling v4l2_device_release()
that calls media_device_unregister_entity() again (previously called by
media_device_unregister(mdev)

Helen

>
> There are issues though, until the patches fixing object referencing are
> finished and merged. Unfortunately I haven't been able to work on those
> recently, will pick them up again soon...
>