In the Linux kernel, the following vulnerability has been resolved: net:
implement lockless setsockopt(SO_PEEK_OFF) syzbot reported a lockdep
violation [1] involving af_unix support of SO_PEEK_OFF. Since SO_PEEK_OFF
is inherently not thread safe (it uses a per-socket sk_peek_off field),
there is really no point to enforce a pointless thread safety in the
kernel. After this patch : - setsockopt(SO_PEEK_OFF) no longer acquires the
socket lock. - skb_consume_udp() no longer has to acquire the socket lock.
- af_unix no longer needs a special version of sk_set_peek_off(), because
it does not lock u->iolock anymore. As a followup, we could replace
prot->set_peek_off to be a boolean and avoid an indirect call, since we
always use sk_set_peek_off(). [1] WARNING: possible circular locking
dependency detected 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Not tainted
syz-executor.2/30025 is trying to acquire lock: ffff8880765e7d80
(&u->iolock){+.+.}-{3:3}, at: unix_set_peek_off+0x26/0xa0
net/unix/af_unix.c:789 but task is already holding lock: ffff8880765e7930
(sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691
[inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at:
sockopt_lock_sock net/core/sock.c:1060 [inline] ffff8880765e7930
(sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360
net/core/sock.c:1193 which lock already depends on the new lock. the
existing dependency chain (in reverse order) is: -> #1
(sk_lock-AF_UNIX){+.+.}-{0:0}: lock_acquire+0x1e3/0x530
kernel/locking/lockdep.c:5754 lock_sock_nested+0x48/0x100
net/core/sock.c:3524 lock_sock include/net/sock.h:1691 [inline]
__unix_dgram_recvmsg+0x1275/0x12c0 net/unix/af_unix.c:2415
sock_recvmsg_nosec+0x18e/0x1d0 net/socket.c:1046
____sys_recvmsg+0x3c0/0x470 net/socket.c:2801 ___sys_recvmsg
net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939
__sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg
net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline]
__x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_64+0xf9/0x240
entry_SYSCALL_64_after_hwframe+0x6f/0x77 -> #0 (&u->iolock){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add
kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0
kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0
kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530
kernel/locking/lockdep.c:5754 __mutex_lock_common
kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70
kernel/locking/mutex.c:752 unix_set_peek_off+0x26/0xa0
net/unix/af_unix.c:789 sk_setsockopt+0x207e/0x3360
do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307
__sys_setsockopt+0x1ad/0x250 net/socket.c:2334 __do_sys_setsockopt
net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline]
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xf9/0x240
entry_SYSCALL_64_after_hwframe+0x6f/0x77 other info that might help us
debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ----
lock(sk_lock-AF_UNIX); lock(&u->iolock); lock(sk_lock-AF_UNIX);
lock(&u->iolock); *** DEADLOCK*** 1 lock held by syz-executor.2/30025: #0:
ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock
include/net/sock.h:1691 [inline] #0: ffff8880765e7930
(sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060
[inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at:
sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193 stack backtrace: CPU: 0
PID: 30025 Comm: syz-executor.2 Not tainted
6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Hardware name: Google Google C
—truncated—