linux-kernel - Re: [PATCH v4 1/2] locking/lockdep: Forcing subclasses to have same name pointer as their parent class

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZsUFeQP3tz8TXxrU@boqun-archlinux>
Date: Tue, 20 Aug 2024 14:07:05 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: botta633 <bottaawesome633@...il.com>
Cc: linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
	Waiman Long <longman@...hat.com>, linux-ext4@...r.kernel.org,
	syzkaller@...glegroups.com,
	syzbot+7f4a6f7f7051474e40ad@...kaller.appspotmail.com,
	stable@...r.kernel.org
Subject: Re: [PATCH v4 1/2] locking/lockdep: Forcing subclasses to have same
 name pointer as their parent class

Hi Ahmed,

Sorry I was missing some points on title and changelog, please see below
and refer to Documentation/process/maintainer-tip.rst:

The title needs to be something like:

	locking/lockdep: Avoid creating new name string literals in lockdep_set_subclass()

the title and the changlog needs to be in imperative mode.

On Mon, Jul 15, 2024 at 04:26:37PM +0300, botta633 wrote:
> From: Ahmed Ehab <bottaawesome633@...il.com>
> 
> Preventing lockdep_set_subclass from creating a new instance of the

Same here, s/Preventing/Prevent, and when you reference a function, you
want to do "lockdep_set_subclass()" instead of "lockdep_set_subclass".

Besides, overall, you want to structure your changelog as follow:

Syzbot reports a problem that a warning will be triggered while
searching a lock class in look_up_lock_class().

// ^ the problem statement

The cause of the issue is that instead of the existing name of a
lock class, a new name (a string literal) is created and used by
lockdep_set_subclass(), and this results in two lock classes with the
same key but different address of the names, and a WARN_ONCE() is
triggered because of that in look_up_lock_class().

// ^ the analysis of the problem, you can merge the above two into one
// paragraph if that works for you.

To fix this, change lockdep_set_subclass() to use the existing name
instead of a new one. As a result no new name will be created by
lockdep_set_subclass(), hence the warning is avoided.

// ^ the fix.

Please send a new version if these make sense to you. The patch #2 also
needs some changes in the title and changelog, but since that's adding
a new test instead of fixing an issue, you could just write something
like:

Add a test case to ensure that no new name string literal will be
created in lockdep_set_subclass(), otherwise a warning will be triggered
in look_up_lock_class(). Add this to catch the problem in the future.

Thanks!

Regards,
Boqun

> string literal. Hence, we will always have the same class->name among
> parent and subclasses. This prevents kernel panics when looking up a
> lock class while comparing class locks and class names.
> 
> Reported-by: <syzbot+7f4a6f7f7051474e40ad@...kaller.appspotmail.com>
> Fixes: de8f5e4f2dc1f ("lockdep: Introduce wait-type checks")
> Cc: <stable@...r.kernel.org>
> Signed-off-by: Ahmed Ehab <bottaawesome633@...il.com>
> ---
> v3->v4:
>     - Fixed subject line truncation.
> 
>  include/linux/lockdep.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> index 08b0d1d9d78b..df8fa5929de7 100644
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -173,7 +173,7 @@ static inline void lockdep_init_map(struct lockdep_map *lock, const char *name,
>  			      (lock)->dep_map.lock_type)
>  
>  #define lockdep_set_subclass(lock, sub)					\
> -	lockdep_init_map_type(&(lock)->dep_map, #lock, (lock)->dep_map.key, sub,\
> +	lockdep_init_map_type(&(lock)->dep_map, (lock)->dep_map.name, (lock)->dep_map.key, sub,\
>  			      (lock)->dep_map.wait_type_inner,		\
>  			      (lock)->dep_map.wait_type_outer,		\
>  			      (lock)->dep_map.lock_type)
> -- 
> 2.45.2