linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] drm/mm: prevent a potential null-pointer dereference
@ 2020-09-10  2:38 Jing Xiangfeng
  2020-09-10  8:58 ` Christian König
  0 siblings, 1 reply; 3+ messages in thread
From: Jing Xiangfeng @ 2020-09-10  2:38 UTC (permalink / raw)
  To: maarten.lankhorst, mripard, tzimmermann, airlied, daniel,
	nirmoy.das, christian.koenig
  Cc: dri-devel, linux-kernel, jingxiangfeng

The macro 'DECLARE_NEXT_HOLE_ADDR' may hit a potential null-pointer
dereference. So use 'entry' after checking it.

Fixes: 5fad79fd66ff ("drm/mm: cleanup and improve next_hole_*_addr()")
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
---
 drivers/gpu/drm/drm_mm.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index a4a04d246135..6fcf70f71962 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -392,11 +392,14 @@ first_hole(struct drm_mm *mm,
 #define DECLARE_NEXT_HOLE_ADDR(name, first, last)			\
 static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size)	\
 {									\
-	struct rb_node *parent, *node = &entry->rb_hole_addr;		\
+	struct rb_node *parent, *node;					\
 									\
-	if (!entry || RB_EMPTY_NODE(node))				\
+	if (!entry)							\
 		return NULL;						\
 									\
+	node = &entry->rb_hole_addr;					\
+	if (RB_EMPTY_NODE(node))					\
+		return NULL;						\
 	if (usable_hole_addr(node->first, size)) {			\
 		node = node->first;					\
 		while (usable_hole_addr(node->last, size))		\
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] drm/mm: prevent a potential null-pointer dereference
  2020-09-10  2:38 [PATCH] drm/mm: prevent a potential null-pointer dereference Jing Xiangfeng
@ 2020-09-10  8:58 ` Christian König
  2020-09-10 12:35   ` Jing Xiangfeng
  0 siblings, 1 reply; 3+ messages in thread
From: Christian König @ 2020-09-10  8:58 UTC (permalink / raw)
  To: Jing Xiangfeng, maarten.lankhorst, mripard, tzimmermann, airlied,
	daniel, nirmoy.das
  Cc: dri-devel, linux-kernel

Am 10.09.20 um 04:38 schrieb Jing Xiangfeng:
> The macro 'DECLARE_NEXT_HOLE_ADDR' may hit a potential null-pointer
> dereference. So use 'entry' after checking it.

I don't see a potential null-pointer dereference here.

Where should that be?

Christian.

>
> Fixes: 5fad79fd66ff ("drm/mm: cleanup and improve next_hole_*_addr()")
> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
> ---
>   drivers/gpu/drm/drm_mm.c | 7 +++++--
>   1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index a4a04d246135..6fcf70f71962 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -392,11 +392,14 @@ first_hole(struct drm_mm *mm,
>   #define DECLARE_NEXT_HOLE_ADDR(name, first, last)			\
>   static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size)	\
>   {									\
> -	struct rb_node *parent, *node = &entry->rb_hole_addr;		\
> +	struct rb_node *parent, *node;					\
>   									\
> -	if (!entry || RB_EMPTY_NODE(node))				\
> +	if (!entry)							\
>   		return NULL;						\
>   									\
> +	node = &entry->rb_hole_addr;					\
> +	if (RB_EMPTY_NODE(node))					\
> +		return NULL;						\
>   	if (usable_hole_addr(node->first, size)) {			\
>   		node = node->first;					\
>   		while (usable_hole_addr(node->last, size))		\


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] drm/mm: prevent a potential null-pointer dereference
  2020-09-10  8:58 ` Christian König
@ 2020-09-10 12:35   ` Jing Xiangfeng
  0 siblings, 0 replies; 3+ messages in thread
From: Jing Xiangfeng @ 2020-09-10 12:35 UTC (permalink / raw)
  To: Christian König, maarten.lankhorst, mripard, tzimmermann,
	airlied, daniel, nirmoy.das
  Cc: dri-devel, linux-kernel



On 2020/9/10 16:58, Christian König wrote:
> Am 10.09.20 um 04:38 schrieb Jing Xiangfeng:
>> The macro 'DECLARE_NEXT_HOLE_ADDR' may hit a potential null-pointer
>> dereference. So use 'entry' after checking it.
>
> I don't see a potential null-pointer dereference here.
>
> Where should that be?

In current code,the "entry" pointer is checked after entry->rb_hole_addr.
	Thanks
>
> Christian.
>
>>
>> Fixes: 5fad79fd66ff ("drm/mm: cleanup and improve next_hole_*_addr()")
>> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
>> ---
>>   drivers/gpu/drm/drm_mm.c | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
>> index a4a04d246135..6fcf70f71962 100644
>> --- a/drivers/gpu/drm/drm_mm.c
>> +++ b/drivers/gpu/drm/drm_mm.c
>> @@ -392,11 +392,14 @@ first_hole(struct drm_mm *mm,
>>   #define DECLARE_NEXT_HOLE_ADDR(name, first, last)            \
>>   static struct drm_mm_node *name(struct drm_mm_node *entry, u64
>> size)    \
>>   {                                    \
>> -    struct rb_node *parent, *node = &entry->rb_hole_addr;        \
>> +    struct rb_node *parent, *node;                    \
>>                                       \
>> -    if (!entry || RB_EMPTY_NODE(node))                \
>> +    if (!entry)                            \
>>           return NULL;                        \
>>                                       \
>> +    node = &entry->rb_hole_addr;                    \
>> +    if (RB_EMPTY_NODE(node))                    \
>> +        return NULL;                        \
>>       if (usable_hole_addr(node->first, size)) {            \
>>           node = node->first;                    \
>>           while (usable_hole_addr(node->last, size))        \
>
> .
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-09-10 12:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-10  2:38 [PATCH] drm/mm: prevent a potential null-pointer dereference Jing Xiangfeng
2020-09-10  8:58 ` Christian König
2020-09-10 12:35   ` Jing Xiangfeng

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).