Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iio: imu: st_lsm6dsx: corregir iio_chan_spec para sensores sin detección de eventos<br /> <br /> El array st_lsm6dsx_acc_channels de la estructura iio_chan_spec tiene un campo event_spec no nulo, indicando soporte para eventos IIO. Sin embargo, la detección de eventos no es compatible con todos los sensores, y si el espacio de usuario intenta configurar eventos de activación del acelerómetro en un dispositivo sensor que no los soporta (p. ej., LSM6DS0), st_lsm6dsx_write_event() desreferencia un puntero NULL al intentar escribir en el registro de activación.<br /> Definir un array adicional de la estructura iio_chan_spec cuyos miembros tienen un campo event_spec NULL, y usar este array en lugar de st_lsm6dsx_acc_channels para sensores sin capacidad de detección de eventos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iio: adc: at91-sama5d2_adc: Soluciona un potencial uso después de liberación en el controlador sama5d2_adc<br /> <br /> at91_adc_interrupt puede llamar a la función at91_adc_touch_data_handler para iniciar el trabajo mediante schedule_work(&amp;amp;st-&amp;gt;touch_st.workq).<br /> <br /> Si eliminamos el módulo que llamará a at91_adc_remove para realizar la limpieza, liberará indio_dev a través de iio_device_unregister pero bastante más tarde. Mientras que el trabajo mencionado anteriormente será utilizado. La secuencia de operaciones que puede llevar a un error UAF es la siguiente:<br /> <br /> CPU0 CPU1<br /> <br /> | at91_adc_workq_handler<br /> at91_adc_remove |<br /> iio_device_unregister(indio_dev) |<br /> //liberar indio_dev un poco más tarde |<br /> | iio_push_to_buffers(indio_dev)<br /> | //usar indio_dev<br /> <br /> Se soluciona asegurando que el trabajo sea cancelado antes de proceder con la limpieza en at91_adc_remove.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Desde la versión 1.65.0 hasta antes de la 1.114.3, el uso de Buffer.allocUnsafe() y Buffer.allocUnsafeSlow() en el ejecutor de tareas permitió que código no confiable asignara memoria no inicializada. Dichos búferes no inicializados podrían contener datos residuales del mismo proceso de Node.js (por ejemplo, datos de solicitudes anteriores, tareas, secretos o tokens), lo que resultaría en una potencial revelación de información. Este problema ha sido parcheado en la versión 1.114.3.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/ena: corregir bloqueo faltante al actualizar los parámetros de devlink<br /> <br /> Corregir la advertencia de bloqueo de aserción al llamar a devl_param_driverinit_value_set() en ena.<br /> <br /> ADVERTENCIA: net/devlink/core.c:261 at devl_assert_locked+0x62/0x90, CPU#0: kworker/0:0/9<br /> CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 No contaminado 6.19.0-rc2+ #1 PREEMPT(lazy)<br /> Nombre del hardware: Amazon EC2 m8i-flex.4xlarge/, BIOS 1.0 10/16/2017<br /> Cola de trabajo: events work_for_cpu_fn<br /> RIP: 0010:devl_assert_locked+0x62/0x90<br /> <br /> Traza de llamada:<br /> <br /> devl_param_driverinit_value_set+0x15/0x1c0<br /> ena_devlink_alloc+0x18c/0x220 [ena]<br /> ? __pfx_ena_devlink_alloc+0x10/0x10 [ena]<br /> ? trace_hardirqs_on+0x18/0x140<br /> ? lockdep_hardirqs_on+0x8c/0x130<br /> ? __raw_spin_unlock_irqrestore+0x5d/0x80<br /> ? __raw_spin_unlock_irqrestore+0x46/0x80<br /> ? devm_ioremap_wc+0x9a/0xd0<br /> ena_probe+0x4d2/0x1b20 [ena]<br /> ? __lock_acquire+0x56a/0xbd0<br /> ? __pfx_ena_probe+0x10/0x10 [ena]<br /> ? local_clock+0x15/0x30<br /> ? __lock_release.isra.0+0x1c9/0x340<br /> ? mark_held_locks+0x40/0x70<br /> ? lockdep_hardirqs_on_prepare.part.0+0x92/0x170<br /> ? trace_hardirqs_on+0x18/0x140<br /> ? lockdep_hardirqs_on+0x8c/0x130<br /> ? __raw_spin_unlock_irqrestore+0x5d/0x80<br /> ? __raw_spin_unlock_irqrestore+0x46/0x80<br /> ? __pfx_ena_probe+0x10/0x10 [ena]<br /> ......<br />

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> libceph: hacer que calc_target() establezca t-&amp;gt;paused, no solo lo borre<br /> <br /> Actualmente, calc_target() borra t-&amp;gt;paused si la solicitud ya no debería estar en pausa, pero nunca establece t-&amp;gt;paused a pesar de que es capaz de determinar cuándo la solicitud debería estar en pausa. El establecimiento de t-&amp;gt;paused se deja a __submit_request(), lo cual está bien para las solicitudes regulares pero no funciona para las solicitudes persistentes (linger requests) -- ya que __submit_request() no opera en solicitudes persistentes, no hay dónde establecer lreq-&amp;gt;t.paused. Una consecuencia de esto es que las vigilancias no se restablecen en las transiciones de pausado -&amp;gt; despausado en casos donde las solicitudes han estado en pausa el tiempo suficiente para que la solicitud de desvigilancia (unwatch) (pausada) expire y para que la solicitud de (re)vigilancia (re)watch subsiguiente entre en el estado de pausa. Además de que la vigilancia no se restablece, rbd_reregister_watch() se queda atascado con rbd_dev-&amp;gt;watch_mutex retenido:<br /> <br /> rbd_register_watch<br /> __rbd_register_watch<br /> ceph_osdc_watch<br /> linger_reg_commit_wait<br /> <br /> Está esperando que lreq-&amp;gt;reg_commit_wait se complete, pero para que eso suceda la solicitud respectiva necesita terminar en la lista need_resend_linger y ser activada cuando las solicitudes se despausan. No hay posibilidad de eso si la solicitud en cuestión nunca se marca como pausada en primer lugar.<br /> <br /> El hecho de que rbd_dev-&amp;gt;watch_mutex permanezca retenido indefinidamente entonces evita que la imagen se desmapee -- &amp;#39;rbd unmap&amp;#39; se colgaría inevitablemente en estado D en un intento de tomar el mutex.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> virtio_net: corrige la falta de coincidencia de dispositivo en devm_kzalloc/devm_kfree<br /> <br /> La asignación inicial de rss_hdr utiliza virtio_device-&amp;gt;device,<br /> pero virtnet_set_queues() libera utilizando net_device-&amp;gt;device.<br /> Esta falta de coincidencia de dispositivo causa la siguiente advertencia de devres<br /> <br /> [ 3788.514041] ------------[ cut here ]------------<br /> [ 3788.514044] WARNING: drivers/base/devres.c:1095 at devm_kfree+0x84/0x98, CPU#16: vdpa/1463<br /> [ 3788.514054] Modules linked in: octep_vdpa virtio_net virtio_vdpa [last unloaded: virtio_vdpa]<br /> [ 3788.514064] CPU: 16 UID: 0 PID: 1463 Comm: vdpa Tainted: G W 6.18.0 #10 PREEMPT<br /> [ 3788.514067] Tainted: [W]=WARN<br /> [ 3788.514069] Hardware name: Marvell CN106XX board (DT)<br /> [ 3788.514071] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> [ 3788.514074] pc : devm_kfree+0x84/0x98<br /> [ 3788.514076] lr : devm_kfree+0x54/0x98<br /> [ 3788.514079] sp : ffff800084e2f220<br /> [ 3788.514080] x29: ffff800084e2f220 x28: ffff0003b2366000 x27: 000000000000003f<br /> [ 3788.514085] x26: 000000000000003f x25: ffff000106f17c10 x24: 0000000000000080<br /> [ 3788.514089] x23: ffff00045bb8ab08 x22: ffff00045bb8a000 x21: 0000000000000018<br /> [ 3788.514093] x20: ffff0004355c3080 x19: ffff00045bb8aa00 x18: 0000000000080000<br /> [ 3788.514098] x17: 0000000000000040 x16: 000000000000001f x15: 000000000007ffff<br /> [ 3788.514102] x14: 0000000000000488 x13: 0000000000000005 x12: 00000000000fffff<br /> [ 3788.514106] x11: ffffffffffffffff x10: 0000000000000005 x9 : ffff800080c8c05c<br /> [ 3788.514110] x8 : ffff800084e2eeb8 x7 : 0000000000000000 x6 : 000000000000003f<br /> [ 3788.514115] x5 : ffff8000831bafe0 x4 : ffff800080c8b010 x3 : ffff0004355c3080<br /> [ 3788.514119] x2 : ffff0004355c3080 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 3788.514123] Call trace:<br /> [ 3788.514125] devm_kfree+0x84/0x98 (P)<br /> [ 3788.514129] virtnet_set_queues+0x134/0x2e8 [virtio_net]<br /> [ 3788.514135] virtnet_probe+0x9c0/0xe00 [virtio_net]<br /> [ 3788.514139] virtio_dev_probe+0x1e0/0x338<br /> [ 3788.514144] really_probe+0xc8/0x3a0<br /> [ 3788.514149] __driver_probe_device+0x84/0x170<br /> [ 3788.514152] driver_probe_device+0x44/0x120<br /> [ 3788.514155] __device_attach_driver+0xc4/0x168<br /> [ 3788.514158] bus_for_each_drv+0x8c/0xf0<br /> [ 3788.514161] __device_attach+0xa4/0x1c0<br /> [ 3788.514164] device_initial_probe+0x1c/0x30<br /> [ 3788.514168] bus_probe_device+0xb4/0xc0<br /> [ 3788.514170] device_add+0x614/0x828<br /> [ 3788.514173] register_virtio_device+0x214/0x258<br /> [ 3788.514175] virtio_vdpa_probe+0xa0/0x110 [virtio_vdpa]<br /> [ 3788.514179] vdpa_dev_probe+0xa8/0xd8<br /> [ 3788.514183] really_probe+0xc8/0x3a0<br /> [ 3788.514186] __driver_probe_device+0x84/0x170<br /> [ 3788.514189] driver_probe_device+0x44/0x120<br /> [ 3788.514192] __device_attach_driver+0xc4/0x168<br /> [ 3788.514195] bus_for_each_drv+0x8c/0xf0<br /> [ 3788.514197] __device_attach+0xa4/0x1c0<br /> [ 3788.514200] device_initial_probe+0x1c/0x30<br /> [ 3788.514203] bus_probe_device+0xb4/0xc0<br /> [ 3788.514206] device_add+0x614/0x828<br /> [ 3788.514209] _vdpa_register_device+0x58/0x88<br /> [ 3788.514211] octep_vdpa_dev_add+0x104/0x228 [octep_vdpa]<br /> [ 3788.514215] vdpa_nl_cmd_dev_add_set_doit+0x2d0/0x3c0<br /> [ 3788.514218] genl_family_rcv_msg_doit+0xe4/0x158<br /> [ 3788.514222] genl_rcv_msg+0x218/0x298<br /> [ 3788.514225] netlink_rcv_skb+0x64/0x138<br /> [ 3788.514229] genl_rcv+0x40/0x60<br /> [ 3788.514233] netlink_unicast+0x32c/0x3b0<br /> [ 3788.514237] netlink_sendmsg+0x170/0x3b8<br /> [ 3788.514241] __sys_sendto+0x12c/0x1c0<br /> [ 3788.514246] __arm64_sys_sendto+0x30/0x48<br /> [ 3788.514249] invoke_syscall.constprop.0+0x58/0xf8<br /> [ 3788.514255] do_el0_svc+0x48/0xd0<br /> [ 3788.514259] el0_svc+0x48/0x210<br /> [ 3788.514264] el0t_64_sync_handler+0xa0/0xe8<br /> [ 3788.514268] el0t_64_sync+0x198/0x1a0<br /> [ 3788.514271] ---[ end trace 0000000000000000 ]---<br /> <br /> Solución mediante el uso de virtio_device-&amp;gt;device de forma consistente para la asignación y desasignación

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> udp: llamar a skb_orphan() antes de skb_attempt_defer_free()<br /> <br /> La ruta de recepción UDP estándar no utiliza skb-&amp;gt;destructor.<br /> <br /> Pero la capa skmsg sí lo utiliza, ya que llama a skb_set_owner_sk_safe() desde udp_read_skb().<br /> <br /> Esto entonces activa esta advertencia en skb_attempt_defer_free():<br /> <br /> DEBUG_NET_WARN_ON_ONCE(skb-&amp;gt;destructor);<br /> <br /> Debemos llamar a skb_orphan() para solucionar este problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bnxt_en: Corrección de un fallo por puntero NULL en bnxt_ptp_enable durante la limpieza de errores<br /> <br /> Cuando bnxt_init_one() falla durante la inicialización (p. ej., bnxt_init_int_mode devuelve -ENODEV), la ruta de error llama a bnxt_free_hwrm_resources() que destruye el pool de DMA y establece bp-&amp;gt;hwrm_dma_pool a NULL. Posteriormente, se llama a bnxt_ptp_clear(), que invoca a ptp_clock_unregister().<br /> <br /> Desde el commit a60fc3294a37 (&amp;#39;ptp: rework ptp_clock_unregister() to disable events&amp;#39;), ptp_clock_unregister() ahora llama a ptp_disable_all_events(), que a su vez invoca la función de callback .enable() del controlador (bnxt_ptp_enable()) para deshabilitar los eventos PTP antes de completar el desregistro.<br /> <br /> bnxt_ptp_enable() intenta enviar comandos HWRM a través de bnxt_ptp_cfg_pin() y bnxt_ptp_cfg_event(), ambas llaman a hwrm_req_init(). Esta función intenta asignar memoria de bp-&amp;gt;hwrm_dma_pool, causando una desreferencia de puntero NULL:<br /> <br /> bnxt_en 0000:01:00.0 (net_device sin nombre) (no inicializado): bnxt_init_int_mode err: ffffffed<br /> KASAN: desreferencia de puntero nulo en el rango [0x0000000000000028-0x000000000000002f]<br /> Traza de Llamadas:<br /> __hwrm_req_init (drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c:72)<br /> bnxt_ptp_enable (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:323 drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:517)<br /> ptp_disable_all_events (drivers/ptp/ptp_chardev.c:66)<br /> ptp_clock_unregister (drivers/ptp/ptp_clock.c:518)<br /> bnxt_ptp_clear (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:1134)<br /> bnxt_init_one (drivers/net/ethernet/broadcom/bnxt/bnxt.c:16889)<br /> <br /> Las líneas son contra el commit f8f9c1f4d0c7 (&amp;#39;Linux 6.19-rc3&amp;#39;)<br /> <br /> Solucione esto limpiando y desregistrando ptp (bnxt_ptp_clear()) antes de liberar los recursos HWRM.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: corrige la desreferencia de puntero NULL en do_abort_log_replay()<br /> <br /> Coverity informó un problema de desreferencia de puntero NULL (CID 1666756) en do_abort_log_replay(). Cuando btrfs_alloc_path() falla en replay_one_buffer(), wc-&amp;gt;subvol_path es NULL, pero btrfs_abort_log_replay() llama a do_abort_log_replay() que desreferencia incondicionalmente wc-&amp;gt;subvol_path al intentar imprimir información de depuración. Esto se corrige añadiendo una comprobación de NULL antes de desreferenciar wc-&amp;gt;subvol_path en do_abort_log_replay().

Una vulnerabilidad existe en los Servicios de Entrada de Contenedores F5 BIG-IP que puede permitir permisos excesivos para leer secretos del clúster. Nota: Las versiones de software que han alcanzado el Fin del Soporte Técnico (EoTS) no son evaluadas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: mac80211_hwsim: corregir errata en la notificación de frecuencia<br /> <br /> La notificación NAN es para 5745 MHz, que corresponde al canal 149 y no a 5475, que en realidad no es un canal válido. Esto podría resultar en una desreferencia de puntero NULL en cfg80211_next_nan_dw_notif.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> idpf: corrección de la desconexión del dispositivo auxiliar cuando rdma no es compatible con el vport<br /> <br /> Si los flags del vport no contienen VIRTCHNL2_VPORT_ENABLE_RDMA, el controlador no asigna vdev_info para este vport. Esto lleva a una desreferencia de puntero NULL del kernel en idpf_idc_vport_dev_down(), que referencia vdev_info para cada vport independientemente.<br /> <br /> Compruebe si vdev_info fue alguna vez asignado antes de desconectar el dispositivo auxiliar.