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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ppp: no asuma que bh se mantiene en ppp_channel_bridge_input() La ruta de recepción de red generalmente se maneja desde el controlador BH. Sin embargo, algunos protocolos necesitan adquirir el bloqueo del socket y los paquetes pueden almacenarse en el backlog del socket si el socket era propiedad de un proceso de usuario. En este caso, release_sock(), __release_sock() y sk_backlog_rcv() pueden llamar al controlador sk->sk_backlog_rcv() en el contexto del proceso. sybot capturó que ppp no estaba considerando este caso en ppp_channel_bridge_input(): ADVERTENCIA: estado de bloqueo inconsistente 6.11.0-rc7-syzkaller-g5f5673607153 #0 No contaminado -------------------------------- uso inconsistente de {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W}. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] toma: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, en: spin_lock include/linux/spinlock.h:351 [en línea] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, en: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [en línea] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, en: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 El estado {SOFTIRQ-ON-W} se registró en: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [en línea] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [en línea] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [en línea] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv incluir/net/sock.h:1111 [en línea] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [en línea] __se_sys_sendto net/socket.c:2212 [en línea] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __invoke_syscall arch/arm64/kernel/syscall.c:35 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 marca de evento de irq: 282914 hardirqs habilitados por última vez en (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [en línea] hardirqs habilitados por última vez en (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs deshabilitados por última vez en (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [en línea] hardirqs se desactivó por última vez en (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs se activó por última vez en (282904): [] softirq_handle_end kernel/softirq.c:400 [en línea] softirqs se activó por última vez en (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs se desactivó por última vez en (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** BLOQUEO INTERMEDIO *** 1 bloqueo mantenido por ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, en: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 seguimiento de pila: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 No contaminado 6.11.0-rc7-syzkaller-g5f5673607153 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Seguimiento de llamadas: dump_backtrace+0x1b8/0x1e4 arch/ar---truncado---