[syzbot] BUG: spinlock already unlocked in corrupted

[syzbot] BUG: spinlock already unlocked in corrupted

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    03897066069f tipc: raise the minimum bearer MTU to fit tun..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
console output: https://syzkaller.appspot.com/x/log.txt?x=10c2fca1580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d30e1495ee3ac817
dashboard link: https://syzkaller.appspot.com/bug?extid=b29ed72382b0e218323a
compiler:       Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17f95969580000

AI-generated root cause summary:
In drivers/block/nbd.c, nbd_add_socket() retrieves a user-supplied socket fd via
nbd_get_socket() and invokes nbd_reclassify_socket(sock) to assign NBD-specific
lockdep classes to the socket. When CONFIG_DEBUG_LOCK_ALLOC is enabled,
nbd_reclassify_socket() performs an unsynchronized check
sock_allow_reclassification(sk) and calls sock_lock_init_class_and_name(sk,
...), which is an initialization macro that not only sets lockdep keys but also
resets sk->sk_lock.owned to 0, reinitializes sk->sk_lock.wq, and calls
spin_lock_init(&sk->sk_lock.slock). Because userspace retains the socket fd,
concurrent socket operations (such as inet_shutdown() calling lock_sock() or
release_sock()) can acquire sk->sk_lock.slock immediately after the check;
spin_lock_init() then reinitializes the active lock to the unlocked state,
causing debug_spin_unlock() to trigger a "BUG: spinlock already unlocked" kernel
panic.

full analysis:  https://syzkaller.appspot.com/x/ai_root_cause?x=b29ed72382b0e218323a

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

Warning: Permanently added '10.128.0.74' (ED25519) to the list of known hosts.
[*] Starting reproducer for BUG: spinlock already unlocked in inet_shutdown...
[+] Detected 2 online CPUs.
[+] open /dev/nbd0 successful (fd=3).
[+] open /dev/nbd1 successful (fd=3).
[+] open /dev/nbd2 successful (fd=3).
[+] open /dev/nbd3 successful (fd=3).
[+] open /dev/nbd4 successful (fd=3).
[+] open /dev/nbd5 successful (fd=3).
[+] open /dev/nbd6 successful (fd=3).
[+] open /dev/nbd7 successful (fd=3).
[+] open /dev/nbd8 successful (fd=3).
[+] open /dev/nbd9 successful (fd=3).
[+] open /dev/nbd10 successful (fd=3).
[+] All 11 NBD devices initialized and verified.
[+] Server socket created.
[+] setsockopt(SO_REUSEADDR) successful.
[+] Server socket bound to 127.0.0.1.
[+] getsockname successful (port=43427).
[+] Server socket listening.
[+] Client socket created.
[+] Client socket connected.
[+] Accepted client connection on server.
[+] Server listening socket closed.
[+] Accepted peer socket closed (peer EOF).
[+] setsockopt(SOL_TCP, TCP_REPAIR, TCP_REPAIR_ON) successful.
[+] Shared TCP socket ready (fd=4).
[+] Started 5 reclassifier threads on devices 0..4.
[+] Started 6 runner threads on devices 5..10.
[+] Started disconnector thread.
[*] Racing NBD_SET_SOCK against NBD_DO_IT (recv_work) and inet_shutdown...


---
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.

If the report is already addressed, 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 report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

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

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

Re: [syzbot] BUG: spinlock already unlocked in corrupted

[Hillf Danton]

> Date: Thu, 05 Nov 2026 03:09:49 -0800	[thread overview]
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    03897066069f tipc: raise the minimum bearer MTU to fit tun..
> git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
> console output: https://syzkaller.appspot.com/x/log.txt?x=10c2fca1580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d30e1495ee3ac817
> dashboard link: https://syzkaller.appspot.com/bug?extid=b29ed72382b0e218323a
> compiler:       Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17f95969580000
> 
> 
> AI-generated root cause summary:
> In drivers/block/nbd.c, nbd_add_socket() retrieves a user-supplied socket fd via
> nbd_get_socket() and invokes nbd_reclassify_socket(sock) to assign NBD-specific
> lockdep classes to the socket. When CONFIG_DEBUG_LOCK_ALLOC is enabled,
> nbd_reclassify_socket() performs an unsynchronized check
> sock_allow_reclassification(sk) and calls sock_lock_init_class_and_name(sk,
> ...), which is an initialization macro that not only sets lockdep keys but also
> resets sk->sk_lock.owned to 0, reinitializes sk->sk_lock.wq, and calls
> spin_lock_init(&sk->sk_lock.slock). Because userspace retains the socket fd,
> concurrent socket operations (such as inet_shutdown() calling lock_sock() or
> release_sock()) can acquire sk->sk_lock.slock immediately after the check;
> spin_lock_init() then reinitializes the active lock to the unlocked state,
> causing debug_spin_unlock() to trigger a "BUG: spinlock already unlocked" kernel
> panic.
> 
Correct, Eric's patch is tested a HBC, with which deadlock is still reported [11,12,13,14]

[11] Subject: [syzbot] possible deadlock in wg_ratelimiter_uninit
https://lore.kernel.org/lkml/6aece79e.382bd2ce.33e041.0001.GAE@google.com/

[12] Subject: [syzbot] [net?] possible deadlock in sk_stream_wait_memory
https://lore.kernel.org/lkml/6aec646f.aca85a03.3b899.0000.GAE@google.com/

[13] Subject: [syzbot] [fs?] [mm?] possible deadlock in hugetlbfs_file_mmap
https://lore.kernel.org/lkml/6aec66fc.059f5055.2712e4.0001.GAE@google.com/

[14] Subject: [syzbot] [cgroups?] possible deadlock in cpuset_can_attach
https://lore.kernel.org/lkml/6aec699e.73adde43.12e2c1.0001.GAE@google.com/


> full analysis:  https://syzkaller.appspot.com/x/ai_root_cause?x=b29ed72382b0e218323a
>
author	Eric Dumazet <edumazet@google.com>	2026-06-13 04:26:19 +0000
committer	Jens Axboe <axboe@kernel.dk>	2026-06-13 06:34:34 -0600
commit	d532cddb6c6049ced414d64d83c6ce7149a6421a (patch)
tree	8f6571fb1cf0c7087ab584a07828a1e3f993ee44 /drivers/block/nbd.c
parent	e8dcf2d142bd720c8334233ad6cfdf00f0e76b7f (diff)
download	linux-d532cddb6c6049ced414d64d83c6ce7149a6421a.tar.gz

nbd: Reclassify sockets to avoid lockdep circular dependency

syzbot reported a possible circular locking dependency in udp_sendmsg()
where fs_reclaim can be triggered while holding sk_lock, and fs_reclaim
can eventually depend on another sk_lock (e.g., if NBD is used for swap
or writeback and NBD uses TLS/TCP which acquires sk_lock).

Since the UDP socket and the NBD TCP/TLS socket are different, this is a
false positive. Fix this by reclassifying NBD sockets to a separate lock
class when they are added to the NBD device.

This is similar to what nvme-tcp and other network block devices do.