Vulnerabilidad en kernel de Linux (CVE-2024-26732)

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