We free dcd_key on line 897 and then dereference it a few lines below.
This patch adds a NULL check to make sure we can use dcd_key.
Signed-off-by: Emil Goode <[email protected]>
---
drivers/staging/tidspbridge/rmgr/dbdcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/tidspbridge/rmgr/dbdcd.c b/drivers/staging/tidspbridge/rmgr/dbdcd.c
index 3d2a26f..21ce3b7 100644
--- a/drivers/staging/tidspbridge/rmgr/dbdcd.c
+++ b/drivers/staging/tidspbridge/rmgr/dbdcd.c
@@ -899,7 +899,7 @@ int dcd_register_object(struct dsp_uuid *uuid_obj,
}
}
spin_unlock(&dbdcd_lock);
- if (&dcd_key->link == ®_key_list)
+ if (dcd_key && (&dcd_key->link == ®_key_list))
status = -EPERM;
}
--
1.7.10.4
1) This patch doesn't do anything. "dcd_key" points to freed memory
but it's not a NULL pointer.
2) The original pointer doesn't dereference "dcd_key" it just takes
the address of one of the elements. I don't know the context and
can't say for sure that it's a wrong thing to do.
The code does look very suspect. Why is it checking permisions
after we already removed the element and freed it?
But it's not a dereferencing freed memory bug.
regards,
dan carpenter
Thank you Dan! That's right, It's of course not NULL after freed.
Yes the code looks strange here, I'm not sure what was intended.
Best regards,
Emil
On Wed, Jun 12, 2013 at 08:08:17AM -0700, Dan Carpenter wrote:
> 1) This patch doesn't do anything. "dcd_key" points to freed memory
> but it's not a NULL pointer.
> 2) The original pointer doesn't dereference "dcd_key" it just takes
> the address of one of the elements. I don't know the context and
> can't say for sure that it's a wrong thing to do.
>
> The code does look very suspect. Why is it checking permisions
> after we already removed the element and freed it?
>
> But it's not a dereferencing freed memory bug.
>
> regards,
> dan carpenter
>