lkml.org 
[lkml]   [2018]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 16/24] locking/lockdep: Retain the class key and name while freeing a lock class
From
Date
On 12/03/2018 07:28 PM, Bart Van Assche wrote:
> The next patch in this series uses the class name in code that
> detects lock class use-after-free. Hence retain the class name for
> lock classes that are being freed.
>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Waiman Long <longman@redhat.com>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
> kernel/locking/lockdep.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index ecd92969674c..92bdb187987f 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -4147,10 +4147,8 @@ static void zap_class(struct lock_class *class)
> * Unhash the class and remove it from the all_lock_classes list:
> */
> hlist_del_rcu(&class->hash_entry);
> + class->hash_entry.pprev = NULL;
> list_del(&class->lock_entry);
> -page
> - RCU_INIT_POINTER(class->key, NULL);
> - RCU_INIT_POINTER(class->name, NULL);
> }
>
> static inline int within(const void *addr, void *start, unsigned long size)

Using the name after module unload can be problematic if it points to
memory space occupied by the unloaded kernel module. The memory page may
be invalid with the potential of crashing the kernel. You may have to
duplicate the name if it is really from the module address space.

Cheers,
Longman

\
 
 \ /
  Last update: 2018-12-04 19:58    [W:0.158 / U:0.924 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site