CVE-2024-26732
net: implement lockless setsockopt(SO_PEEK_OFF)
Severity Score
Exploit Likelihood
Affected Versions
Public Exploits
0Exploited in Wild
-Decision
Descriptions
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---
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: implementar lockless setsockopt(SO_PEEK_OFF) syzbot informó una violación de lockdep [1] que involucraba el soporte de SO_PEEK_OFF por parte de af_unix. Dado que SO_PEEK_OFF no es inherentemente seguro para subprocesos (utiliza un campo sk_peek_off por socket), realmente no tiene sentido imponer una seguridad de subprocesos inútil en el kernel. Después de este parche: - setsockopt(SO_PEEK_OFF) ya no adquiere el bloqueo del socket. - skb_consume_udp() ya no tiene que adquirir el bloqueo del socket. - af_unix ya no necesita una versión especial de sk_set_peek_off(), porque ya no bloquea u->iolock. Como seguimiento, podríamos reemplazar prot->set_peek_off para que sea booleano y evitar una llamada indirecta, ya que siempre usamos sk_set_peek_off(). [1] ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 No contaminado syz-executor.2/30025 está intentando adquirir el bloqueo: ffff8880765e7d80 (&u->iolock){+.+. }-{3:3}, en: unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789 pero la tarea ya mantiene el bloqueo: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, en: lock_sock include/net/sock.h:1691 [en línea] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, en: sockopt_lock_sock net/core/sock.c:1060 [en línea] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, en: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #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 [en línea] __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 [en línea] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [en línea] __do_sy s_recvmmsg red/socket .c:3041 [en línea] __se_sys_recvmmsg net/socket.c:3034 [en línea] __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 [en línea] check_prevs_add kernel/locking/lockdep.c:3253 [en línea] validar_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 [en línea] __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/ enchufe.c: 2334 __do_sys_setsockopt net/socket.c:2343 [en línea] __se_sys_setsockopt net/socket.c:2340 [en línea] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xf9/0x240 entrada_SYSCALL_6 4_after_hwframe+0x6f/0x77 otra información que podría ayudar depuremos esto: Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock(sk_lock-AF_UNIX); bloquear(&u->iolock); bloquear(sk_lock-AF_UNIX); bloquear(&u->iolock); *** DEADLOCK *** 1 bloqueo retenido por syz-executor.2/30025: #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, en: lock_sock include/net/sock. h:1691 [en línea] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, en: sockopt_lock_sock net/core/sock.c:1060 [en línea] #0: ffff8880765e7930 (sk_lock- AF_UNIX){+.+.}-{0:0}, en: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193 seguimiento de pila: CPU: 0 PID: 30025 Comm: syz-executor.2 No contaminado 6.8 .0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Nombre del hardware: Google Google C ---truncado---
CVSS Scores
SSVC
- Decision:Track
Timeline
- 2024-02-19 CVE Reserved
- 2024-04-03 CVE Published
- 2024-04-04 EPSS Updated
- 2024-08-02 CVE Updated
- ---------- Exploited in Wild
- ---------- KEV Due Date
- ---------- First Exploit
CWE
CAPEC
References (3)
URL | Tag | Source |
---|---|---|
https://git.kernel.org/stable/c/859051dd165ec6cc915f0f2114699021144fd249 | Vuln. Introduced |
URL | Date | SRC |
---|
URL | Date | SRC |
---|---|---|
https://git.kernel.org/stable/c/897f75e2cde8a5f9f7529b55249af1fa4248c83b | 2024-03-01 | |
https://git.kernel.org/stable/c/56667da7399eb19af857e30f41bea89aa6fa812c | 2024-02-21 |
URL | Date | SRC |
---|
Affected Vendors, Products, and Versions
Vendor | Product | Version | Other | Status | ||||||
---|---|---|---|---|---|---|---|---|---|---|
Vendor | Product | Version | Other | Status | <-- --> | Vendor | Product | Version | Other | Status |
Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 6.7 < 6.7.7 Search vendor "Linux" for product "Linux Kernel" and version " >= 6.7 < 6.7.7" | en |
Affected
| ||||||
Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 6.7 < 6.8 Search vendor "Linux" for product "Linux Kernel" and version " >= 6.7 < 6.8" | en |
Affected
|