[PATCH] af_unix: Fix wrong socket tested in the symmetric half of unix_state_lock_cmp_fn().

[PATCH] af_unix: Fix wrong socket tested in the symmetric half of unix_state_lock_cmp_fn().

[lirongqing]

From: Li RongQing <lirongqing@baidu.com>

The second half of unix_state_lock_cmp_fn() is meant to mirror the
first one with the roles of a and b swapped, but it switches on b's
state again:

	if (b->sk.sk_state == TCP_LISTEN) {
		switch (b->sk.sk_state) {
		case TCP_CLOSE:
		case TCP_ESTABLISHED:
			return 1;

The enclosing if already established that b is TCP_LISTEN, so the
switch can only reach the default label and the branch always returns
0, "no order known", instead of the intended 1.

Test a's state, as the first half does.  The code is only compiled with
CONFIG_PROVE_LOCKING, so there is no runtime memory-safety impact; the
effect is that lockdep cannot validate this nesting order of
unix_state_lock().

Fixes: 98f706de445b ("af_unix: Define locking order for U_LOCK_SECOND in unix_stream_connect().")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 net/unix/af_unix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index e7a0582..501e693 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -163,7 +163,7 @@ static int unix_state_lock_cmp_fn(const struct lockdep_map *_a,
 
 	/* Should never happen.  Just to be symmetric. */
 	if (b->sk.sk_state == TCP_LISTEN) {
-		switch (b->sk.sk_state) {
+		switch (a->sk.sk_state) {
 		case TCP_CLOSE:
 		case TCP_ESTABLISHED:
 			return 1;
-- 
2.9.4

Re: [PATCH] af_unix: Fix wrong socket tested in the symmetric half of unix_state_lock_cmp_fn().

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.