Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: bridge: cdns-mhdp8546: corrige posible desreferencia del puntero nulo En cdns_mhdp_atomic_enable(), el valor de retorno de drm_mode_duplicate() se asigna a mhdp_state->current_mode, y hay una desreferencia de él en drm_mode_set_name(), lo que conducirá a una desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Solucione este error y agregue una verificación de mhdp_state->current_mode.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: kirkwood: corrige una posible desreferencia NULL En kirkwood_dma_hw_params() mv_mbus_dram_info() devuelve NULL si la macro CONFIG_PLAT_ORION no está definida. Corrija este error agregando una verificación NULL. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: Asignar dummy cuando el códec no está especificado para un enlace DAI Los controladores de la tarjeta de sonido MediaTek están comprobando si hay un enlace DAI presente y utilizado en una placa para asignar los parámetros correctos y esto se realiza comprobando los nombres DAI del códec en el momento de la sonda. Si no hay ningún códec real, asigne el códec ficticio al enlace DAI para evitar el puntero NULL durante la comparación de cadenas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ax25: Solucionar el problema de fuga del recuento de referencias de net_device Hay un problema de fuga del recuento de referencias del objeto "net_device" en ax25_dev_device_down(). Cuando el dispositivo ax25 se está apagando, ax25_dev_device_down() elimina el recuento de referencia de net_device una o cero veces dependiendo de si vamos a unlock_put o no, lo que provocará una pérdida de memoria. Para resolver el problema anterior, reduzca el recuento de referencias de net_device después de que dev->ax25_ptr se establezca en nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: descartar la finalización de comandos en caso de error interno. Se corrige el use-after-free cuando llega la finalización del FW mientras el dispositivo está en estado de error interno. Evite llamar al controlador de finalización en este caso, ya que el dispositivo limpiará la interfaz de comando y activará todas las finalizaciones manualmente. Registro del kernel: ------------[ cortar aquí ]------------ refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0xd8/0xe0 ... Seguimiento de llamadas: ? __advertir+0x79/0x120 ? refcount_warn_saturate+0xd8/0xe0? report_bug+0x17c/0x190? handle_bug+0x3c/0x60? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? refcount_warn_saturate+0xd8/0xe0 cmd_ent_put+0x13b/0x160 [mlx5_core] mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core] cmd_comp_notifier+0x1f/0x30 [mlx5_core] notifier_call_chain+0x35/0xb0 cadena+0x16/0x20 mlx5_eq_async_int+0xf6/0x290 [mlx5_core] notifier_call_chain+0x35 /0xb0 atomic_notifier_call_chain+0x16/0x20 irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x4b/0x160 handle_irq_event+0x2e/0x80 handle_edge_irq+0x98/0x230 __common_interrupt+0x3b/0 xa0 interrupción_común+0x7b/0xa0 asm_interrupción_común+0x22 /0x40

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: agrega un tiempo de espera para adquirir el semáforo de la cola de comandos. Evita el manejo de finalización forzada en una entrada a la que aún no se le ha asignado un índice, lo que provoca un acceso fuera de los límites en idx = -22. En lugar de esperar indefinidamente el sem, el flujo de bloqueo ahora espera a que se asigne el índice o a que se agote el tiempo de espera de adquisición del sem antes de iniciar el temporizador para completar el FW. Ejemplo de registro del kernel: mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No se completó

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: recarga solo los representantes IB al desactivar/activar el retraso. Al desactivar el retraso, el dispositivo IB de enlace junto con todos sus representantes se destruyen y luego se recargan los representantes de los esclavos. . En caso de que falle la carga del representante IB esclavo, el flujo de error de conmutación descarga todos los representantes, incluidos los representantes de Ethernet, donde los netdevs se desconectan y se eliminan del vínculo de retraso. Dicho flujo es inexacto ya que el controlador de retraso no es responsable de cargar/descargar representantes de Ethernet. Además, el flujo descrito anteriormente comienza manteniendo el bloqueo de retardo para evitar cambios de unión durante la desactivación del flujo. Sin embargo, cuando se alcanza la separación del retraso de los representantes de Ethernet, se requiere nuevamente el bloqueo del retraso, lo que desencadena el siguiente punto muerto: Seguimiento de llamadas: __switch_to+0xf4/0x148 __schedule+0x2c8/0x7d0 Schedule+0x50/0xe0 Schedule_preempt_disabled+0x18/0x28 __mutex_lock.isra. 13+0x2b8/0x570 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x4c/0x68 mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core] mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core] 6c/0xb0 [mlx5_core] mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x28 /0x38 [mlx5_core] mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core] mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core] mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core] 138 [mlx5_core] mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // mantenga presionado ldev- >bloquear mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core] devlink_nl_cmd_eswitch_set_doit+0xdc/0x180 genl_family_rcv_msg_doit.isra.17+0xe8/0x138 genl_rcv_msg+0xe4/0x220 b+0x44/0x108 genl_rcv+0x40/0x58 netlink_unicast+0x198/0x268 netlink_sendmsg+0x1d4/0x418 sock_sendmsg +0x54/0x60 __sys_sendto+0xf4/0x120 __arm64_sys_sendto+0x30/0x40 el0_svc_common+0x8c/0x120 do_el0_svc+0x30/0xa0 el0_svc+0x20/0x30 el0_sync_handler+0x90/0xb8 el0_sync+0x160/0x180 Por lo tanto, tras el retraso habilitar/deshabilitar, cargar y descargar sólo los representantes IB de los esclavos evitan el punto muerto mencionado anteriormente. Mientras lo hace, refactorice la función mlx5_esw_offloads_rep_load() para tener un método auxiliar estático para su lógica interna, en simetría con el diseño de descarga del representante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fec: elimine .ndo_poll_controller para evitar interbloqueos. Se encontró un problema de interbloqueo en el controlador sungem; consulte el commit ac0a230f719b ("eth: sungem: elimine .ndo_poll_controller para evitar interbloqueos "). La causa principal del problema es que netpoll está en un contexto atómico y la interfaz .ndo_poll_controller del controlador sungem llama a enable_irq(); sin embargo, enable_irq() puede estar inactivo. Después de analizar la implementación de fec_poll_controller(), el controlador fec debería tener el mismo problema. Debido a que el controlador fec utiliza NAPI para las completaciones de TX, no es necesario implementar .ndo_poll_controller en el controlador fec, por lo que fec_poll_controller() se puede eliminar de forma segura.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/mediatek: Agregar verificación de tamaño 0 a mtk_drm_gem_obj Agregar una verificación a mtk_drm_gem_init si intentamos asignar un objeto GEM de 0 bytes. Actualmente, no existe tal verificación y el kernel entrará en pánico si una aplicación de espacio de usuario intenta asignar un búfer GBM 0x0. Probado intentando asignar un búfer GBM 0x0 en un MT8188 y verificando que ahora devolvemos EINVAL.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige un posible índice fuera de los límites en la función de transformación de color. Corrige el problema de índice fuera de los límites en la función de transformación de color. El problema podría ocurrir cuando el índice 'i' excede la cantidad de puntos de función de transferencia (TRANSFER_FUNC_POINTS). La solución agrega una verificación para garantizar que 'i' esté dentro de los límites antes de acceder a los puntos de función de transferencia. Si 'i' está fuera de los límites, se registra un mensaje de error y la función devuelve falso para indicar un error. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: desbordamiento del búfer 'output_tf->tf_pts.red' 1025 <= controladores s32max/gpu /drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: desbordamiento del búfer 'output_tf->tf_pts.green' 1025 <= controladores s32max/gpu/drm/amd/amdgpu/ ../display/dc/dcn10/dcn10_cm_common.c:407 error de cm_helper_translate_curve_to_hw_format(): desbordamiento del búfer 'output_tf->tf_pts.blue' 1025 <= s32max

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch: corrige la sobrescritura de la tupla original de ct para ICMPv6 OVS_PACKET_CMD_EXECUTE tiene 3 atributos principales: - OVS_PACKET_ATTR_KEY - Metadatos de paquetes en formato netlink. - OVS_PACKET_ATTR_PACKET: contenido del paquete binario. - OVS_PACKET_ATTR_ACTIONS: acciones a ejecutar en el paquete. OVS_PACKET_ATTR_KEY se analiza primero para completar la estructura sw_flow_key con metadatos como el estado de conexión, el puerto de entrada, la identificación de recirculación, etc. Luego, el paquete en sí se analiza para completar el resto de las claves de los encabezados del paquete. Siempre que el código de análisis de paquetes comienza a analizar el encabezado ICMPv6, primero pone a cero los campos en la clave correspondiente a la información de descubrimiento de vecinos, incluso si no es un paquete ND. Es un campo 'ipv6.nd'. Sin embargo, 'ipv6' es una unión que comparte el espacio entre 'nd' y 'ct_orig' que contiene los metadatos de conntrack de tupla originales analizados a partir de OVS_PACKET_ATTR_KEY. Los paquetes ND normalmente no deberían tener estado de seguimiento, por lo que está bien compartir el espacio, pero los paquetes ICMPv6 Echo normales o tal vez otros tipos de ICMPv6 pueden tener el estado adjunto y no deben sobrescribirse. El problema provoca que todos, excepto los últimos 4 bytes de la dirección de destino, se borren de la tupla conntrack original, lo que provoca una coincidencia incorrecta de paquetes y, potencialmente, la ejecución de acciones incorrectas en caso de que este paquete recircule dentro de la ruta de datos o regrese al espacio de usuario. No se debe acceder a los campos ND en paquetes que no sean ND, por lo que no borrarlos debería estar bien. Ejecutar memset() solo para paquetes ND reales para evitar el problema. Es necesario inicializar todo antes del análisis porque es posible que el paquete ND no contenga todas las opciones. El problema solo afecta la ruta OVS_PACKET_CMD_EXECUTE y no afecta a los paquetes que ingresan a la ruta de datos OVS desde las interfaces de red, porque en este caso los metadatos CT se completan desde skb después de que el paquete ya se haya analizado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/cma: corrija kmemleak en rdma_core observado durante el uso de blktests nvme/rdma siw Al ejecutar blktests nvme/rdma, aparecerá el siguiente problema de kmemleak. kmemleak: detector de pérdida de memoria del kernel inicializado (mempool disponible: 36041) kmemleak: hilo de escaneo automático de memoria iniciado kmemleak: 2 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) kmemleak: 8 nuevas pérdidas de memoria sospechosas (ver /sys/ kernel/debug/kmemleak) kmemleak: 17 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) kmemleak: 4 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) objeto sin referencia 0xffff88855da53400 (tamaño 192): comm "rdma", pid 10630, sjiffies 4296575922 volcado hexadecimal (primeros 32 bytes): 37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7................. 10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.].... backtrace (crc 47f66721): [] kmalloc_trace+0x30d/0x3b0 [< ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core] [] add_modify_gid+0x166/0x930 [ib_core] [] ib_cache_update.part.0+0x6d8/0x910 [ib_core] [] ib_cache_setup_one+0x24a/ 0x350 [ib_core] [] ib_register_device+0x9e/0x3a0 [ib_core] [] 0xffffffffc2a3d389 [] nldev_newlink+0x2b8/0x520 [ib_core] ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core] [ ] rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core] [] netlink_unicast+0x445/0x710 [] 0 [] __sys_sendto+0x3a9/0x420 [] __x64_sys_sendto+0xdc/0x1b0 [] do_syscall_64+0x93/0x180 [] Entry_SYSCALL_64_after_hwframe+0x71/0x79 La causa raíz: _gid_attr no se llama cuando sgid_attr está configurado en ERR_PTR(-ENODEV).