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@xxxxxxxxxx/

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

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

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


> full analysis:  https://syzkaller.appspot.com/x/ai_root_cause?x=b29ed72382b0e218323a
>
author	Eric Dumazet <edumazet@xxxxxxxxxx>	2026-06-13 04:26:19 +0000
committer	Jens Axboe <axboe@xxxxxxxxx>	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.