Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: algif_hash - Eliminar SGL falso libre en ruta de error de longitud cero Cuando algif_hash codifica un mensaje de longitud cero y se activa un error, intenta liberar una lista de SG que nunca fue asignado en primer lugar. Solucione este problema al no liberar la lista SG en la ruta de error de longitud cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: nci: rx_data_reassembly skb gratuito en la limpieza del dispositivo NCI rx_data_reassembly skb se almacena durante el intercambio de datos NCI para procesar paquetes fragmentados. Se elimina solo cuando se procesa el último fragmento o cuando se recibe un paquete NTF con el código de operación NCI_OP_RF_DEACTIVATE_NTF. Sin embargo, el dispositivo NCI puede desasignarse antes de lo que provoca una fuga de skb. Como por diseño el skb rx_data_reassembly está vinculado al dispositivo NCI y nada impide que el dispositivo se libere antes de que el skb se procese y limpie de alguna manera, libérelo en la limpieza del dispositivo NCI. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrige la reinyección de datos desde un subflujo obsoleto Cuando MPTCP PM detecta que un subflujo está obsoleto, todo el programador de paquetes debe reinyectar todos los datos no codificados del nivel mptcp. Para evitar adquirir bloqueos innecesarios, primero intenta verificar si hay datos no bloqueados presentes en la cola RTX, pero dicha verificación actualmente no funciona, ya que utiliza un asistente específico de TCP en un socket MPTCP. Curiosamente, los fuzzers y los comprobadores estáticos están contentos, ya que la memoria a la que se accede todavía pertenece a la estructura mptcp_sock, e incluso desde una perspectiva funcional la recuperación se completó con éxito, ya que la prueba de acceso directo siempre fallaba. Un cambio reciente de TCP no relacionado (commit d5fed5addb2b ("tcp: reorganizar las variables de ruta rápida de tcp_sock")) expuso el problema, ya que la reorganización del campo tcp hace que el código mptcp siempre omita la reinección. Solucione el problema eliminando la llamada falsa: estamos en un camino lento, la optimización inicial demostró una vez más ser mala.

Motivo del rechazo: este ID CVE ha sido rechazado o retirado por su autoridad de numeración CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: corrige el desbordamiento insuficiente en parse_server_interfaces() En este bucle, recorremos el búfer y después de cada elemento comprobamos si size_left es mayor que el tamaño mínimo que necesitamos. Sin embargo, el problema es que "bytes_left" es del tipo ssize_t mientras que sizeof() es del tipo size_t. Eso significa que debido a la promoción de tipo, la comparación se realiza sin firmar y si nos quedan bytes negativos, el ciclo continúa en lugar de finalizar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: ir_toy: corrige una fuga de mem en irtoy_tx Cuando falla irtoy_command, se debe liberar buf ya que está asignado por irtoy_tx, o hay una fuga de mem.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: No permitir que VF que no es de confianza elimine la MAC configurada administrativamente. Actualmente, cuando PF configura administrativamente la dirección MAC de VF y el VF se desactiva (VF intenta eliminar todas las MAC), entonces la MAC se eliminado de los filtros MAC y el MAC VF primario se pone a cero. No permita que VF que no es de confianza elimine la MAC principal cuando PF la configuró administrativamente. Reproductor: 1) Crear VF 2) Configurar la interfaz VF 3) Configurar administrativamente la MAC del VF 4) Colocar la interfaz VF [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@ host ~]# enlace ip establecido enp2s0f0v0 up [root@host ~]# enlace ip establecido enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# enlace ip show enp2s0f0 23: enp2s0f0: < BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq estado Modo UP DEFAULT grupo predeterminado qlen 1000 enlace/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 enlace/ ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, verificación de suplantación de identidad activada, estado de enlace automático, confianza desactivada [root@host ~]# enlace IP configurado enp2s0f0v0 inactivo [raíz @host ~]# ip link show enp2s0f0 23: enp2s0f0: mtu 1500 qdisc mq state Modo UP DEFAULT grupo predeterminado qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff :ff:ff:ff:ff:ff vf 0 enlace/éter 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, verificación de suplantación de identidad activada, estado de enlace automático, confianza desactivada

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/handshake: Fix handshake_req_destroy_test1 Recientemente, handshake_req_destroy_test1 comenzó a fallar: Se esperaba handshake_req_destroy_test == req, pero handshake_req_destroy_test == 0000000000000000 req == 0000000060f99b40 no ok 11 req_destroy funciona Esto se debe a que "sock_release( calcetín)" fue reemplazado por "fput(filp)" para solucionar una pérdida de memoria. Tenga en cuenta que sock_release() es sincrónico pero fput() normalmente retrasa el cierre y la limpieza finales. El retraso no tiene consecuencias en los otros casos que se cambiaron, pero handshake_req_destroy_test1 está probando que handshake_req_cancel() seguido del cierre del archivo realmente llama al método ->hp_destroy. Por lo tanto, la prueba PTR_EQ al final debe asegurarse de que el cierre final esté completo antes de verificar el puntero. No podemos usar una finalización aquí porque si nunca se llama a ->hp_destroy (es decir, hay un error de API), la prueba se bloqueará. Reportado por: Guenter Roeck

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: zswap: corrige la limpieza de folio faltante en la ruta de carrera de escritura diferida En zswap_writeback_entry(), después de obtener un folio de __read_swap_cache_async(), tomamos el bloqueo del árbol nuevamente para verificar que el intercambio la entrada no fue invalidada y reciclada. Si así fuera, eliminamos la publicación que acabamos de agregar al caché de intercambio y salimos. Sin embargo, __read_swap_cache_async() devuelve la publicación bloqueada cuando se asigna recientemente, lo que siempre es cierto para esta ruta, y la publicación se ref. Asegúrate de desbloquear y colocar el folio antes de regresar. Esto se descubrió mediante la inspección del código, probablemente porque esta ruta maneja una condición de carrera que no debería ocurrir con frecuencia, y el error no bloquearía el sistema, solo bloqueará la publicación indefinidamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige la pérdida de memoria en dm_sw_fini() Después de destruir dmub_srv, la memoria asociada a él no se libera, lo que provoca una pérdida de memoria: objeto sin referencia 0xffff896302b45800 (tamaño 1024) : comm "(udev-worker)", pid 222, sjiffies 4294894636 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........... ..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc 6265fd77): [] kmalloc_trace+ 0x29d/0x340 [] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [] dm_sw_init+0x15/0x2b0 [amdgpu] [] 1417/0x24e0 [amdgpu] [] amdgpu_driver_load_kms+0x15 /0x190 [amdgpu] [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [] local_pci_probe+0x3e/0x90 [] pci_device_probe+0xc3/0x230 [ ] realmente_probe+0xe2/0x480 [< ffffffff99805c98>] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] v+0x70/0xc0 [] bus_add_driver+0x112/0x210 [< ffffffff99807245>] driver_register+0x55/0x100 [] do_one_initcall+0x41/0x300 Solucione este problema liberando dmub_srv después de destruirlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_flow_offload: libera dst en caso de que se use la ruta de xmit directa Direct xmit no la usa ya que llama a dev_queue_xmit() para enviar paquetes, por lo tanto llama a dst_release(). informes kmemleak: objeto sin referencia 0xffff88814f440900 (tamaño 184): comm "softirq", pid 0, jiffies 4294951896 volcado hexadecimal (primeros 32 bytes): 00 60 5b 04 81 88 ff ff 00 e6 e8 82 ff ff ff ff .`[.. ........... 21 0b 50 82 ff ff ff ff 00 00 00 00 00 00 00 00 !.P................. retroceso (crc cb2bf5d6): [ <000000003ee17107>] kmem_cache_alloc+0x286/0x340 [<0000000021a5de2c>] dst_alloc+0x43/0xb0 [<00000000f0671159>] rt_dst_alloc+0x2e/0x190 [<00000000fe50 92c9>] __mkroute_output+0x244/0x980 [<000000005fb96fb0>] ip_route_output_flow+0xc0/0x160 [ <0000000045367433>] nf_ip_route+0xf/0x30 [<0000000085da1d8e>] nf_route+0x2d/0x60 [<00000000d1ecd1cb>] nft_flow_route+0x171/0x6a0 [nft_flow_offload] 0000d9b2fb60>] nft_flow_offload_eval+0x4e8/0x700 [nft_flow_offload] [<000000009f447dbb>] expr_call_ops_eval+0x53/0x330 [nf_tables] [<00000000072e1be6>] nft_do_chain+0x17c/0x840 [nf_tables] [<00000000d0551029>] nft_do_chain_inet+0xa1/0x210 [nf_tables] [ <0000000097c9d5c6>] nf_hook_slow+0x5b/0x160 [<0000000005eccab1>] ip_forward +0x8b6/0x9b0 [<00000000553a269b>] ip_rcv+0x221/0x230 [<00000000412872e5>] __netif_receive_skb_one_core+0xfe/0x110

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: establece el indicador inactivo en caso de error en el registro del enlace. Necesitamos configurar el indicador inactivo nuevamente si no logramos registrar los enlaces. Durante la presión de la memoria, el registro de ganchos puede fallar y terminamos con una tabla marcada como activa pero sin ganchos registrados. Al eliminar la tabla/cadena base, nf_tables intentará cancelar el registro del gancho nuevamente, lo que genera un símbolo de advertencia desde el núcleo de nftables.