Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: dp83822: Se corrige la desreferencia del puntero NULL en los dispositivos DP83825 La función probe() solo se usa para DP83822 y DP83826 PHY, lo que deja el puntero de datos privados sin inicializar para los modelos DP83825, lo que provoca una desreferencia del puntero NULL en las funciones recientemente introducidas/cambiadas dp8382x_config_init() y dp83822_set_wol(). Agregue la función dp8382x_probe(), para que todos los modelos PHY tengan un puntero de datos privados válido para solucionar este problema y también evitar problemas similares en el futuro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7921: se corrige el acceso al puntero NULL en mt7921_ipv6_addr_change. Al deshabilitar wifi, se llama a mt7921_ipv6_addr_change() como notificador. En este punto, mvif->phy ya es NULL, por lo que no podemos usarlo aquí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet: ipheth: no detiene RX en caso de error en la devolución de llamada RX Las devoluciones de llamada RX pueden fallar por múltiples razones: * Payload demasiado corto * Payload formateado incorrectamente (por ejemplo, mala estructura de NCM) * Falta de memoria Ninguna de estas debería provocar que el controlador se bloquee. Haga que estas fallas no sean críticas y continúe procesando más URB entrantes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: soc-acpi-intel-mtl-match: agregar elemento vacío faltante No hay links_num en struct snd_soc_acpi_mach {}, y probamos !link->num_adr como condición para finalizar el bucle en hda_sdw_machine_select(). Por lo tanto, se requiere un elemento vacío en la matriz struct snd_soc_acpi_link_adr.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: soc-acpi-intel-lnl-match: agregar elemento vacío faltante No hay links_num en struct snd_soc_acpi_mach {}, y probamos !link->num_adr como condición para finalizar el bucle en hda_sdw_machine_select(). Por lo tanto, se requiere un elemento vacío en la matriz struct snd_soc_acpi_link_adr.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/hyperv: fix kexec crash due to VP assist page corrupt commit 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg management when CPUs go online/offline") introduce un nuevo estado de cpuhp para la inicialización de hyperv. cpuhp_setup_state() devuelve el número de estado si el estado es CPUHP_AP_ONLINE_DYN o CPUHP_BP_PREPARE_DYN y 0 para todos los demás estados. Para el caso de hyperv, dado que se introdujo un nuevo estado de cpuhp, devolvería 0. Sin embargo, en hv_machine_shutdown(), la llamada a cpuhp_remove_state() está condicionada a "hyperv_init_cpuhp > 0". Esto nunca será cierto y, por lo tanto, hv_cpu_die() no se llamará en todas las CPU. Esto significa que la página de asistencia de VP no se restablecerá. Cuando el kernel de kexec intenta configurar la página de asistencia de VP nuevamente, el hipervisor corrompe la región de memoria de la página de asistencia de VP anterior, lo que provoca un pánico en caso de que el kernel de kexec esté usando esa memoria en otro lugar. Esto se solucionó originalmente en el commit dfe94d4086e4 ("x86/hyperv: Fix kexec panic/hang issues"). Deshágase de hyperv_init_cpuhp por completo, ya que ya no estamos usando un estado de cpuhp dinámico y use CPUHP_AP_HYPERV_ONLINE directamente con cpuhp_remove_state().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/client: añadir bloqueo de bo faltante en show_meminfo() bo_meminfo() quiere inspeccionar el estado de bo como tt y el recurso ttm, sin embargo, este estado puede cambiar en cualquier momento y provocar problemas como NPD y UAF, si no se mantiene el bloqueo de bo. Toma el bloqueo de bo al llamar a bo_meminfo(), asegurándote de que eliminamos primero cualquier spinlock. En el caso de object_idr, ahora también necesitamos mantener una referencia. v2 (MattB) - También añade xe_bo_assert_held() (seleccionado de el commit 4f63d712fa104c3ebefcb289d1e733e86d8698c7)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/client: se corrige el bloqueo en show_meminfo(). Hay un bloqueo real, así como un error de suspensión en atomic(), si resulta que la put de bo es la última referencia, ya que la destrucción de bo quiere tomar el mismo spinlock y los bloqueos inactivos. Arregle eso eliminando la referencia usando xe_bo_put_deferred() y moviendo el commit final fuera del bloqueo. Eliminar el bloqueo alrededor de la put es complicado, ya que el bo puede salir del ámbito y eliminarse a sí mismo de la lista, lo que dificulta la navegación a la siguiente entrada de la lista. (seleccionado de el commit 0083b8e6f11d7662283a267d4ce7c966812ffd8a)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dpaa: Paquetes de relleno a ETH_ZLEN Al enviar paquetes de menos de 60 bytes, se pueden filtrar hasta tres bytes del búfer que sigue a los datos. Evite esto extendiendo todos los paquetes a ETH_ZLEN, asegurándose de que no se filtre nada en el relleno. Este error se puede reproducir ejecutando $ ping -s 11 destination

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_socket: corrige fugas de referencias de sk Debemos poner la referencia 'sk' antes de regresar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Corregir operaciones en modo puente cuando no hay VF Actualmente, intentar establecer el atributo de modo puente cuando numvfs=0 provoca un bloqueo: bridge link set dev eth2 hwmode vepa [ 168.967392] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000030 [...] [ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core] [...] [ 168.976037] Seguimiento de llamadas: [ 168.976188] [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core] [ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core] [ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0 [ 168.979714] rtnetlink_rcv_msg+0x159/0x400 [ 168.980451] netlink_rcv_skb+0x54/0x100 [ 168.980675] netlink_unicast+0x241/0x360 [ 168.980918] netlink_sendmsg+0x1f6/0x430 [ 168.981162] ____sys_sendmsg+0x3bb/0x3f0 [ 168.982155] ___sys_sendmsg+0x88/0xd0 [ 168.985036] __sys_sendmsg+0x59/0xa0 [ 168.985477] do_syscall_64+0x79/0x150 [ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 168.987773] RIP: 0033:0x7f8f7950f917 (esw->fdb_table.legacy.vepa_fdb es nulo) El modo puente solo es relevante cuando hay varias funciones por puerto. Por lo tanto, evite configurar y obtener esta configuración cuando no haya VF. Tenga en cuenta que después de este cambio, no hay configuraciones para cambiar en la interfaz PF usando "enlace de puente" cuando no hay VF, por lo que la interfaz ya no aparece en la salida del "enlace de puente".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp:pm: Se corrige uaf en __timer_delete_sync Hay dos rutas para acceder a mptcp_pm_del_add_timer, lo que genera una condición de carrera: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entrada) En remove_anno_list_by_saddr(que se ejecuta en la CPU2), después de salir de la zona crítica protegida por "pm.lock", se liberará la entrada, lo que lleva a la aparición de uaf en mptcp_pm_del_add_timer(que se ejecuta en la CPU1). Mantener una referencia a add_timer dentro del bloqueo y llamar a sk_stop_timer_sync() con esta referencia, en lugar de "entrada->add_timer". Mueva list_del(&entry->list) a mptcp_pm_del_add_timer y dentro del bloqueo pm, no acceda directamente a ningún miembro de la entrada fuera del bloqueo pm, lo que puede evitar un uaf "entry->x" similar.