[syzbot] [hams?] general protection fault in prepare_to_wait (2)

[syzbot] [hams?] general protection fault in prepare_to_wait (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    ace0ab3a4b54 Revert "vlan: Fix VLAN 0 memory leak"
git tree:       net
console+strace: https://syzkaller.appspot.com/x/log.txt?x=152cdb63a80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=3e670757e16affb
dashboard link: https://syzkaller.appspot.com/bug?extid=666c97e4686410e79649
compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10a80fc3a80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/e03bf2f0ff9c/disk-ace0ab3a.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ad6e79c01723/vmlinux-ace0ab3a.xz
kernel image: https://storage.googleapis.com/syzbot-assets/617319e5afb7/bzImage-ace0ab3a.xz

Bisection is inconclusive: the issue happens on the oldest tested release.

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=157eda9ba80000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=177eda9ba80000
console output: https://syzkaller.appspot.com/x/log.txt?x=137eda9ba80000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+666c97e4686410e79649@syzkaller.appspotmail.com

general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 0 PID: 5059 Comm: syz-executor.0 Not tainted 6.5.0-rc5-syzkaller-00194-gace0ab3a4b54 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
RIP: 0010:__lock_acquire+0x109/0x5de0 kernel/locking/lockdep.c:5012
Code: 45 85 c9 0f 84 cc 0e 00 00 44 8b 05 11 6e 23 0b 45 85 c0 0f 84 be 0d 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 d1 48 c1 e9 03 <80> 3c 11 00 0f 85 e8 40 00 00 49 81 3a a0 69 48 90 0f 84 96 0d 00
RSP: 0018:ffffc90003d6f9e0 EFLAGS: 00010006
RAX: ffff8880244c8000 RBX: 1ffff920007adf6c RCX: 0000000000000003
RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 0000000000000018
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000018 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f51d519a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f51d5158d58 CR3: 000000002943f000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 lock_acquire kernel/locking/lockdep.c:5761 [inline]
 lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0x3a/0x50 kernel/locking/spinlock.c:162
 prepare_to_wait+0x47/0x380 kernel/sched/wait.c:269
 nr_accept+0x20d/0x650 net/netrom/af_netrom.c:798
 do_accept+0x3a6/0x570 net/socket.c:1872
 __sys_accept4_file net/socket.c:1913 [inline]
 __sys_accept4+0x99/0x120 net/socket.c:1943
 __do_sys_accept4 net/socket.c:1954 [inline]
 __se_sys_accept4 net/socket.c:1951 [inline]
 __x64_sys_accept4+0x96/0x100 net/socket.c:1951
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f51d447cae9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f51d519a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000120
RAX: ffffffffffffffda RBX: 00007f51d459bf80 RCX: 00007f51d447cae9
RDX: 0000000020000400 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 00007f51d44c847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000800 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f51d459bf80 R15: 00007ffc25c34e48
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__lock_acquire+0x109/0x5de0 kernel/locking/lockdep.c:5012
Code: 45 85 c9 0f 84 cc 0e 00 00 44 8b 05 11 6e 23 0b 45 85 c0 0f 84 be 0d 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 d1 48 c1 e9 03 <80> 3c 11 00 0f 85 e8 40 00 00 49 81 3a a0 69 48 90 0f 84 96 0d 00
RSP: 0018:ffffc90003d6f9e0 EFLAGS: 00010006
RAX: ffff8880244c8000 RBX: 1ffff920007adf6c RCX: 0000000000000003
RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 0000000000000018
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000018 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f51d519a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f51d5158d58 CR3: 000000002943f000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
   0:	45 85 c9             	test   %r9d,%r9d
   3:	0f 84 cc 0e 00 00    	je     0xed5
   9:	44 8b 05 11 6e 23 0b 	mov    0xb236e11(%rip),%r8d        # 0xb236e21
  10:	45 85 c0             	test   %r8d,%r8d
  13:	0f 84 be 0d 00 00    	je     0xdd7
  19:	48 ba 00 00 00 00 00 	movabs $0xdffffc0000000000,%rdx
  20:	fc ff df
  23:	4c 89 d1             	mov    %r10,%rcx
  26:	48 c1 e9 03          	shr    $0x3,%rcx
* 2a:	80 3c 11 00          	cmpb   $0x0,(%rcx,%rdx,1) <-- trapping instruction
  2e:	0f 85 e8 40 00 00    	jne    0x411c
  34:	49 81 3a a0 69 48 90 	cmpq   $0xffffffff904869a0,(%r10)
  3b:	0f                   	.byte 0xf
  3c:	84                   	.byte 0x84
  3d:	96                   	xchg   %eax,%esi
  3e:	0d                   	.byte 0xd


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[PATCH] sock: Fix sk_sleep return invalid pointer

[eadavis]

From: Edward AD <eadavis@sina.com>

The parameter sk_sleep(sk) passed in when calling prepare_to_wait may 
return an invalid pointer due to nr-release reclaiming the sock.
Here, schedule_timeout_interruptible is used to replace the combination 
of 'prepare_to_wait, schedule, finish_wait' to solve the problem.

Reported-and-tested-by: syzbot+666c97e4686410e79649@syzkaller.appspotmail.com
Signed-off-by: Edward AD <eadavis@sina.com>
---
 net/netrom/af_netrom.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
index eb8ccbd58d..c84a4c65b3 100644
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -732,23 +732,18 @@ static int nr_connect(struct socket *sock, struct sockaddr *uaddr,
 	 * closed.
 	 */
 	if (sk->sk_state == TCP_SYN_SENT) {
-		DEFINE_WAIT(wait);
-
 		for (;;) {
-			prepare_to_wait(sk_sleep(sk), &wait,
-					TASK_INTERRUPTIBLE);
 			if (sk->sk_state != TCP_SYN_SENT)
 				break;
 			if (!signal_pending(current)) {
 				release_sock(sk);
-				schedule();
+				schedule_timeout_interruptible(HZ);
 				lock_sock(sk);
 				continue;
 			}
 			err = -ERESTARTSYS;
 			break;
 		}
-		finish_wait(sk_sleep(sk), &wait);
 		if (err)
 			goto out_release;
 	}
@@ -772,7 +767,6 @@ static int nr_accept(struct socket *sock, struct socket *newsock, int flags,
 {
 	struct sk_buff *skb;
 	struct sock *newsk;
-	DEFINE_WAIT(wait);
 	struct sock *sk;
 	int err = 0;
 
@@ -795,7 +789,6 @@ static int nr_accept(struct socket *sock, struct socket *newsock, int flags,
 	 *	hooked into the SABM we saved
 	 */
 	for (;;) {
-		prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
 		skb = skb_dequeue(&sk->sk_receive_queue);
 		if (skb)
 			break;
@@ -806,14 +799,13 @@ static int nr_accept(struct socket *sock, struct socket *newsock, int flags,
 		}
 		if (!signal_pending(current)) {
 			release_sock(sk);
-			schedule();
+			schedule_timeout_uninterruptible(HZ);
 			lock_sock(sk);
 			continue;
 		}
 		err = -ERESTARTSYS;
 		break;
 	}
-	finish_wait(sk_sleep(sk), &wait);
 	if (err)
 		goto out_release;
 
-- 
2.25.1

Re: [PATCH] sock: Fix sk_sleep return invalid pointer

[Paolo Abeni]

On Tue, 2023-08-22 at 20:44 +0800, eadavis@sina.com wrote:
> From: Edward AD <eadavis@sina.com>
> 
> The parameter sk_sleep(sk) passed in when calling prepare_to_wait may 
> return an invalid pointer due to nr-release reclaiming the sock.
> Here, schedule_timeout_interruptible is used to replace the combination 
> of 'prepare_to_wait, schedule, finish_wait' to solve the problem.
> 
> Reported-and-tested-by: syzbot+666c97e4686410e79649@syzkaller.appspotmail.com
> Signed-off-by: Edward AD <eadavis@sina.com>

This looks wrong. No syscall should race with sock_release(). It looks
like you are papering over the real issue.

As the reproducer shows a disconnect on an connected socket, I'm wild
guessing something alike 4faeee0cf8a5d88d63cdbc3bab124fb0e6aed08c
should be more appropriate.

Cheers,

Paolo

Re: [PATCH] sock: Fix sk_sleep return invalid pointer

[eadavis]

From: Edward AD <eadavis@sina.com>

On Tue, 22 Aug 2023 17:31:00 +0200, pabeni@redhat.com wrote:
> > From: Edward AD <eadavis@sina.com>
> > 
> > The parameter sk_sleep(sk) passed in when calling prepare_to_wait may 
> > return an invalid pointer due to nr-release reclaiming the sock.
> > Here, schedule_timeout_interruptible is used to replace the combination 
> > of 'prepare_to_wait, schedule, finish_wait' to solve the problem.
> > 
> > Reported-and-tested-by: syzbot+666c97e4686410e79649@syzkaller.appspotmail.com
> > Signed-off-by: Edward AD <eadavis@sina.com>
> 
> This looks wrong. No syscall should race with sock_release(). It looks
> like you are papering over the real issue.
> 
> As the reproducer shows a disconnect on an connected socket, I'm wild
> guessing something alike 4faeee0cf8a5d88d63cdbc3bab124fb0e6aed08c
> should be more appropriate.
There is insufficient evidence to prove where the current report provided by 
syz caused 'sk_sleep()' to return an invalid pointer.
So, the above statement is my guess.