Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: i2c: et8ek8: No eliminar la función de eliminación cuando el controlador está integrado. El uso de __exit para la función de eliminación hace que la devolución de llamada de eliminación se descarte con CONFIG_VIDEO_ET8EK8=y. Cuando un dispositivo de este tipo se desvincula (por ejemplo, usando sysfs o hotplug), el controlador simplemente se elimina sin que se realice la limpieza. Esto da como resultado fugas de recursos. Solucionarlo compilando la devolución de llamada de eliminación incondicionalmente. Esto también corrige una advertencia de modpost W=1: ADVERTENCIA: modpost: drivers/media/i2c/et8ek8/et8ek8: sección no coincide en referencia: et8ek8_i2c_driver+0x10 (sección: .data) -> et8ek8_remove (sección: .exit.text)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ring-buffer: corrige una ejecución entre lectores y cambia el tamaño de las comprobaciones. El código del lector en rb_get_reader_page() intercambia una nueva página del lector en el búfer circular haciendo cmpxchg en old->list.prev ->siguiente para apuntar a la nueva página. Después de eso, si la operación es exitosa, old->list.next->prev también se actualiza. Esto significa que la lista doblemente enlazada subyacente es temporalmente inconsistente, página->anterior->siguiente o página->siguiente->anterior podría no ser igual a la página para alguna página en el búfer circular. La operación de cambio de tamaño en ring_buffer_resize() se puede invocar en paralelo. Llama a rb_check_pages(), que puede detectar la inconsistencia descrita y detener el seguimiento: [190.271762] ------------[ cortar aquí ]------------ [ 190.271771] ADVERTENCIA: CPU: 1 PID: 6186 en kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0 [190.271789] Módulos vinculados en: [...] [190.271991] Módulos contaminados descargados: intel_uncore_frequency(E) :1 skx_edac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: cargado Contaminado: GE 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 01/04/2014 [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0 [ 190.272023] Código: [.. .] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 00000000000000007 RCX: ffff8eba01f13d80 [ 19 0.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 00000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:000000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 [ 190 .272077] Seguimiento de llamadas: [190.272098 ] [ 190.272189] ring_buffer_resize+0x2ab/0x460 [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0 [ 190.272206] tracing_resize_ring_buffer+0x65/0x90 [ 190.272216] _entries_write+0x74/0xc0 [ 190.272225] vfs_write+0xf5/0x420 [ 190.272248 ] ksys_write+0x67/0xe0 [ 190.272256] do_syscall_64+0x82/0x170 [ 190.272363] Entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d26 3 [ 190.272381] Código: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000 000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12 : 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 00000000000000002 [ 190.272412] [ 4] ---[ end trace 0000000000000000 ]--- Tenga en cuenta que ring_buffer_resize() llama a rb_check_pages() solo si el trace_buffer principal tiene grabación desactivada. El reciente commit d78ab792705c ("rastreo: detener el rastreador actual al cambiar el tamaño del búfer") hace que ahora sea siempre el caso, lo que hace que sea más probable experimentar este problema. No obstante, la ventana para llegar a esta ejecución es muy pequeña. Para ayudar a reproducirlo, se puede agregar un bucle de retardo en rb_get_reader_page(): ret = rb_head_page_replace(reader, cpu_buffer->reader_page); if (!ret) ir a girar; for (unsigned i = 0; i < 1U << 26; i++) /* bucle de retardo insertado ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: stmmac: mover el bloqueo EST a la estructura stmmac_priv Reinicializar toda la estructura EST también restablecería el bloqueo mutex que está incrustado en la estructura EST y luego activaría la siguiente advertencia. Para solucionar esto, mueva el candado a la estructura stmmac_priv. También necesitamos volver a adquirir el bloqueo mutex al realizar esta inicialización. DEBUG_LOCKS_WARN_ON(lock->magic != lock) ADVERTENCIA: CPU: 3 PID: 505 en kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Módulos vinculados en: CPU: 3 PID: 505 Comm: tc No contaminado 6.9. 0-rc6-00053-g0106679839f7-dirty #29 Nombre del hardware: NXP i.MX8MPlus Placa EVK (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: __mutex_lock+0xd84/ 0x1068 lr: __mutex_lock+0xd84/0x1068 sp: ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 : ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 00000000000000000 x20: 0000000000000000 x19: c083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: 2bb2640 x9: ffffffc082bb2698 x8: 0000000000017fe8 x7: c0000000fffffff x6: 0000000000000001 x5: ffffff8178fe0d48 x4: 0000000000000000 x3: 00000000 00000027 x2: ffffff8178fe0d50 x1: 0000000000000000 x0: 0000000000000000 Rastreo de llamadas: __mutex_lock+0xd84/0x1068 mutex_lock_nested+0x28/0x34 tc_setup_taprio+0x118/0x68c stmmac_setup_tc+0x50/0xf0 taprio_change+0x868/0xc9c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: corrige el conjunto de enlaces de desarrollo de pares para el puerto devlink del representante SF. El flujo de devlink del registro de cambios de parche citado y no refleja los cambios para la lógica del conjunto de enlaces de desarrollo de pares. El conjunto de devlink de pares activa un seguimiento de llamadas si se realiza después de devl_register.[1] Por lo tanto, alinee la lógica del conjunto de devlink de pares con el flujo de registro de devlink. [1] ADVERTENCIA: CPU: 4 PID: 3394 en net/devlink/core.c:155 devlink_rel_nested_in_add+0x177/0x180 CPU: 4 PID: 3394 Comm: kworker/u40:1 No contaminado 6.9.0-rc4_for_linust_min_debug_2024_04_16_14_0 8 #1 Nombre del hardware : PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Cola de trabajo: mlx5_vhca_event0 mlx5_vhca_state_work_handler [mlx5_core] RIP 0010:devlink_rel_nested_in_ agregar+0x177/0x180 Llamar Seguimiento: ? __advertir+0x78/0x120 ? devlink_rel_nested_in_add+0x177/0x180? report_bug+0x16d/0x180? handle_bug+0x3c/0x60? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? devlink_port_init+0x30/0x30? devlink_port_type_clear+0x50/0x50? devlink_rel_nested_in_add+0x177/0x180? devlink_rel_nested_in_add+0xdd/0x180 mlx5_sf_mdev_event+0x74/0xb0 [mlx5_core] notifier_call_chain+0x35/0xb0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] x5_sf_dev_probe+0x185/0x3e0 [mlx5_core] auxiliar_bus_probe+0x38/0x80? driver_sysfs_add+0x51/0x80 realmente_probe+0xc5/0x3a0? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x8 6/0xa0 dispositivo_add+0x64f/0x860 __auxiliary_device_add+0x3b/0xa0 mlx5_sf_dev_add+0x139/0x330 [mlx5_core] mlx5_sf_dev_state_change_handler+0x1e4/0x250 [mlx5_core] notifier_call_chain+0x35/0xb0 blocking_notifier_call_chain+0x3d/0x60 mlx5_vhca_state_work_handler+0x151/0x200 [mlx5_core Process_one_work+0x13f] /0x2e0 hilo_trabajador+0x2bd/0x3c0 ? hilo_rescate+0x410/0x410 kthread+0xc4/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x2d/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Modifique el nivel de impresión del error CQE. Demasiada impresión puede provocar pánico en el kernel. Cambie ibdev_err() a ibdev_err_ratelimited() y cambie el nivel de impresión del volcado cqe al nivel de depuración.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mediatek: Init `ddp_comp` con devm_kcalloc() En el caso de que `conn_routes` sea verdadero, asignamos una ranura adicional en la matriz `ddp_comp` pero mtk_drm_crtc_create() nunca apareció para inicializarlo en el caso de prueba que ejecuté. Para mí, esto provocó un bloqueo posterior cuando recorrimos la matriz en mtk_drm_crtc_mode_valid(). Esto me apareció cuando arranqué con `slub_debug=FZPUA` que envenena la memoria inicialmente. Sin `slub_debug` no pude reproducir, presumiblemente porque el código posterior maneja que el valor sea NULL y en la mayoría de los casos (no garantizado en todos los casos) la memoria que devolvió el asignador comenzó como 0. Realmente no está de más inicializar el array con devm_kcalloc() ya que la matriz es pequeña y la sobrecarga de iniciar un puñado de elementos en 0 es pequeña. En general, iniciar la memoria a cero es una práctica más segura y, por lo general, se sugiere usar solo las funciones de asignación que no son de inicio si realmente es necesario. Cambiemos la función para usar una función de asignación que ponga a cero la memoria. Para mí, esto evita el accidente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: micrel: Se corrigió la recepción de la marca de tiempo en el framework para lan8841. El commit culpable comenzó a usar la cola de trabajo ptp para obtener la segunda parte de la marca de tiempo. Y cuando se establece el puerto, esta cola de trabajo se detiene. Pero si la opción de configuración NETWORK_PHY_TIMESTAMPING no está habilitada, entonces ptp_clock no se inicializa, por lo que se bloqueará cuando intente acceder al trabajo retrasado. Entonces, básicamente, al configurar y luego desactivar el puerto, fallaría. La solución consiste en comprobar si el ptp_clock está inicializado y sólo entonces cancelar el trabajo retrasado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: sungem: elimine .ndo_poll_controller para evitar interbloqueos Erhard informa advertencias de netpoll desde sungem: netpoll_send_skb_on_dev(): eth0 habilitó interrupciones en la encuesta (gem_start_xmit+0x0/0x398) ADVERTENCIA: CPU: 1 PID: 1 en net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() desactiva las interrupciones, que pueden dormir. No podemos dormir en netpoll, tiene las interrupciones desactivadas por completo. Curiosamente, gem_poll_controller() ni siquiera sondea las finalizaciones y, en cambio, actúa como si se hubiera disparado una interrupción, por lo que simplemente programa NAPI y sale. Nada de esto ha sido necesario durante años, ya que netpoll invoca directamente a NAPI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: soluciona interbloqueos con eliminaciones de kctl al desconectar fin. La devolución de llamada puede eliminar un elemento kctl y esto puede provocar un punto muerto cuando el dispositivo estaba en estado suspendido. Es decir: * Un proceso espera el encendido en snd_power_ref_and_wait() en snd_ctl_info() o lectura/escritura() dentro de card->controls_rwsem. * Mientras tanto, el sistema se desconecta y el controlador intenta eliminar un kctl mediante snd_ctl_remove*(); intenta tomar card->controls_rwsem nuevamente, pero esto ya está bloqueado por lo anterior. Como el durmiente no se despierta, esto se bloquea. Una solución fácil es despertar a los durmientes antes de procesar las devoluciones de llamada de desconexión del controlador, pero justo después de configurar la tarjeta->indicador de apagado. Entonces todos los durmientes abortarán inmediatamente y el código fluirá nuevamente. Básicamente, este parche mueve la llamada wait_event() en el momento adecuado. Mientras estamos en esto, solo para estar seguros, llame a wait_event_all() en lugar de wait_event(), aunque no usamos eventos exclusivos en esta cola por ahora.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/hns: corrige el punto muerto en eventos asíncronos de SRQ. Es posible que se requiera xa_lock para la tabla SRQ en AEQ. Utilice xa_store_irq()/ xa_erase_irq() para evitar un punto muerto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netrom: solucionó un posible bloqueo en nr_rt_ioctl() syzbot ama netrom y encontró un posible bloqueo en nr_rt_ioctl [1] Asegúrese de adquirir siempre nr_node_list_lock antes de nr_node_lock(nr_node) [1 ] ADVERTENCIA: se detectó posible dependencia de bloqueo circular 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 No contaminado --------------------- --------------------- syz-executor350/5129 está intentando adquirir el bloqueo: ffff8880186e2070 (&nr_node->node_lock){+... }-{2:2}, en: spin_lock_bh include/linux/spinlock.h:356 [en línea] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, en: nr_node_lock include/net/ netrom.h:152 [en línea] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, en: nr_dec_obs net/netrom/nr_route.c:464 [en línea] ffff8880186e2070 (&nr_node->node_lock) {+...}-{2:2}, en: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 pero la tarea ya está bloqueada: fffffffff8f7053b8 (nr_node_list_lock){+...}-{2: 2}, en: spin_lock_bh include/linux/spinlock.h:356 [en línea] fffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, en: nr_dec_obs net/netrom/nr_route.c:462 [en línea] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, en: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/ spinlock_api_smp.h:126 [en línea] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [en línea] nr_remove_node net/netrom/nr_route.c:299 [en línea] nr_del_node+ 0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:13 41 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64 +0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep. c:3134 [en línea] check_prevs_add kernel/locking/lockdep.c:3253 [en línea] validar_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed /0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [en línea] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [en línea ] nr_node_lock include/net/netrom.h:152 [en línea] nr_dec_obs net/netrom/nr_route.c:464 [en línea] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket. c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 llamada_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- bloqueo(nr_node_list_lock); bloquear(&nr_nodo->nodo_lock); bloquear(nr_node_list_lock); bloquear(&nr_nodo->nodo_lock); *** DEADLOCK *** 1 bloqueo retenido por syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, en: spin_lock_bh include/linux/spinlock.h:356 [ en línea] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, en: nr_dec_obs net/netrom/nr_route.c:462 [en línea] #0: ffffffff8f70 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: af_unix: corrige ejecucións de datos en unix_release_sock/unix_stream_sendmsg Se identificó una condición de ejecución de datos en af_unix. En una ruta de datos, la función de escritura unix_release_sock() escribe atómicamente en sk->sk_shutdown usando WRITE_ONCE. Sin embargo, en el lado del lector, unix_stream_sendmsg() no lo lee atómicamente. En consecuencia, este problema está provocando que se produzca el siguiente símbolo de KCSAN: ERROR: KCSAN: data-race en unix_release_sock / unix_stream_sendmsg escribe (marcado) en 0xffff88867256ddbb de 1 byte por tarea 7270 en la CPU 28: unix_release_sock (net/unix/af_unix.c: 640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508 ) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/ common.c:?) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) leído en 0xffff88867256ddbb de 1 bytes por la tarea 989 en la CPU 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket .c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/ socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64 .S:130) valor cambiado: 0x01 -> 0x03 Los números de línea están relacionados con el commit dd5a440a31fa ("Linux 6.9-rc7"). El commit e1d09c2c2f57 ("af_unix: corregir ejecucións de datos alrededor de sk->sk_shutdown.") abordó un problema comparable en el pasado con respecto a sk->sk_shutdown. Sin embargo, pasó por alto resolver esta ruta de datos en particular. Este parche solo ofende la función unix_stream_sendmsg(), ya que las otras lecturas parecen estar protegidas por unix_state_lock() como se explica en