Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_set_pipapo: evitar el desbordamiento en la asignación de la tabla de búsqueda Al calcular el tamaño de la tabla de búsqueda, asegúrese de que la siguiente multiplicación no se desborde: - desc->field_len[] el valor máximo es U8_MAX multiplicado por NFT_PIPAPO_GROUPS_PER_BYTE(f) que puede ser 2, en el peor de los casos. - NFT_PIPAPO_BUCKETS(f->bb) es 2^8, en el peor de los casos. - sizeof(unsigned long), de sizeof(*f->lt), lt en struct nft_pipapo_field. Luego, use check_mul_overflow() para multiplicar por el tamaño del depósito y luego use check_add_overflow() para la alineación de avx2 (si es necesario). Finalmente, agregue el ayudante lt_size_check_overflow() y úselo para consolidar esto. Mientras tanto, reemplace la asignación restante usando GFP_KERNEL a GFP_KERNEL_ACCOUNT para mantener la consistencia, en pipapo_resize().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: zona: corrección para evitar inconsistencia entre SIT y SSA con el siguiente caso de prueba, provocará inconsistencia entre SIT y SSA. create_null_blk 512 2 1024 1024 mkfs.f2fs -m /dev/nullb0 mount /dev/nullb0 /mnt/f2fs/ touch /mnt/f2fs/file f2fs_io pinfile set /mnt/f2fs/file fallocate -l 4GiB /mnt/f2fs/file F2FS-fs (nullb0): Segmento inconsistente (0) tipo [1, 0] en SSA y SIT CPU: 5 UID: 0 PID: 2398 Comm: fallocate Contaminado: GO 6.13.0-rc1 #84 Contaminado: [O]=OOT_MODULE Nombre del hardware: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Rastreo de llamadas dump_stack_lvl+0xb3/0xd0 dump_stack+0x14/0x20 f2fs_handle_critical_error+0x18c/0x220 [f2fs] f2fs_stop_checkpoint+0x38/0x50 [f2fs] do_garbage_collect+0x674/0x6e0 [f2fs] f2fs_gc_range+0x12b/0x230 [f2fs] f2fs_allocate_pinning_section+0x5c/0x150 [f2fs] f2fs_expand_inode_data+0x1cc/0x3c0 [f2fs] f2fs_fallocate+0x3c3/0x410 [f2fs] vfs_fallocate+0x15f/0x4b0 __x64_sys_fallocate+0x4a/0x80 x64_sys_call+0x15e8/0x1b80 do_syscall_64+0x68/0x130 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f9dba5197ca F2FS-fs (nullb0): Sistema de archivos detenido por el motivo: 4. El motivo es que f2fs_gc_range() podría intentar migrar un bloque en curseg; sin embargo, su bloque SSA no está actualizado debido a que los últimos datos del bloque de resumen aún se encuentran en la caché de curseg. En este parche, añadimos una condición en f2fs_gc_range() para comprobar si la sección está abierta y omitir la migración del bloque en la sección abierta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Se corrige el pánico al llamar a skb_linearize El pánico se puede reproducir ejecutando el comando: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000 Luego se capturó un pánico del kernel: ''' [ 657.460555] kernel BUG at net/core/skbuff.c:2178! [ 657.462680] Tainted: [W]=WARN [ 657.463287] Workqueue: events sk_psock_backlog ... [ 657.469610] [ 657.469738] ? die+0x36/0x90 [ 657.469916] ? do_trap+0x1d0/0x270 [ 657.470118] ? pskb_expand_head+0x612/0xf40 [ 657.470376] ? pskb_expand_head+0x612/0xf40 [ 657.470620] ? do_error_trap+0xa3/0x170 [ 657.470846] ? pskb_expand_head+0x612/0xf40 [ 657.471092] ? handle_invalid_op+0x2c/0x40 [ 657.471335] ? pskb_expand_head+0x612/0xf40 [ 657.471579] ? exc_invalid_op+0x2d/0x40 [ 657.471805] ? asm_exc_invalid_op+0x1a/0x20 [ 657.472052] ? pskb_expand_head+0xd1/0xf40 [ 657.472292] ? pskb_expand_head+0x612/0xf40 [ 657.472540] ? lock_acquire+0x18f/0x4e0 [ 657.472766] ? find_held_lock+0x2d/0x110 [ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10 [ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470 [ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10 [ 657.473826] __pskb_pull_tail+0xfd/0x1d20 [ 657.474062] ? __kasan_slab_alloc+0x4e/0x90 [ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510 [ 657.475392] ? __kasan_kmalloc+0xaa/0xb0 [ 657.476010] sk_psock_backlog+0x5cf/0xd70 [ 657.476637] process_one_work+0x858/0x1a20 ''' El pánico se origina en la aserción BUG_ON(skb_shared(skb)) en skb_linearize(). Una confirmación anterior (véase la etiqueta "Correcciones") introdujo skb_get() para evitar condiciones de ejecución entre las operaciones de skb en el backlog y la versión de skb en la ruta recvmsg. Sin embargo, esto provocaba que el pánico siempre se produjera al ejecutar skb_linearize. El parámetro "--rx-strp 100000" obliga a la ruta RX a usar el módulo strparser, que agrega datos hasta alcanzar los 100 KB antes de llamar a la lógica de sockmap. El payload de 100 KB supera MAX_MSG_FRAGS, lo que activa skb_linearize. Para solucionar este problema, simplemente mueva skb_get a sk_psock_skb_ingress_enqueue. ''' sk_psock_backlog: sk_psock_handle_skb skb_get(skb) <== lo movemos a 'sk_psock_skb_ingress_enqueue' sk_psock_skb_ingress____________ ? | | ? sk_psock_skb_ingress_self | sk_psock_skb_ingress_enqueue sk_psock_verdict_apply_________________? skb_linearize ''' Tenga en cuenta que para la ruta verdict_apply, la operación skb_get es innecesaria, por lo que añadimos el parámetro 'take_ref' para controlar su comportamiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/cma: Se corrige el bloqueo cuando cma_netevent_callback no puede ejecutar queue_work La confirmación citada corrigió un bloqueo cuando se llamaba a cma_netevent_callback para un cma_id mientras que el trabajo en ese id de una llamada anterior aún no había comenzado. El elemento de trabajo se reinicializó en la segunda llamada, lo que corrompió el elemento de trabajo que se encontraba actualmente en la cola de trabajos. Sin embargo, dejó un problema cuando queue_work falla (porque el elemento sigue pendiente en la cola de trabajos de una llamada anterior). En este caso, por lo tanto, cma_id_put (que se llama en el controlador de trabajos) no se llama. Esto da como resultado un bloqueo del proceso del espacio de usuario (proceso zombi). Arregle esto llamando a cma_id_put() si queue_work falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: usb: aqc111: corrección del manejo de errores de las llamadas de lectura USBnet. Syzkaller, cortesía de syzbot, identificó un error (véase el informe [1]) en el controlador aqc111, causado por una corrección incompleta de los resultados de las llamadas de lectura USB. Este problema es bastante similar al corregido en el commit 920a9fa27e78 ("net: asix: añadir un manejo adecuado de errores de lectura USB"). Por ejemplo, usbnet_read_cmd() puede leer menos bytes que 'size', incluso si el emisor esperaba la cantidad completa, y aqc111_read_cmd() no comprobará su resultado correctamente. Como se muestra en [1], esto puede provocar que la dirección MAC en aqc111_bind() se inicialice solo parcialmente, lo que activa advertencias KMSAN. Solucione el problema verificando que el número de bytes leídos sea el esperado y no menor. [1] Informe parcial de syzbot: ERROR: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline] BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 is_valid_ether_addr include/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] really_probe+0x4d1/0xd90 drivers/base/dd.c:658 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800 ... Uninit was stored to memory at: dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582 __dev_addr_set include/linux/netdevice.h:4874 [inline] eth_hw_addr_set include/linux/etherdevice.h:325 [inline] aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 ... Uninit was stored to memory at: ether_addr_copy include/linux/etherdevice.h:305 [inline] aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline] aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] ... Local variable buf.i created at: aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline] aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7915: Se corrige la desreferencia de puntero nulo en mt7915_mmio_wed_init(). devm_ioremap() devuelve NULL en caso de error. Actualmente, mt7915_mmio_wed_init() no verifica este caso, lo que resulta en una desreferencia de puntero nulo. Se debe evitar la desreferencia de puntero nulo en mt7915_mmio_wed_init().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7996: Se ha corregido la vulnerabilidad null-ptr-deref en mt7996_mmio_wed_init(). Devm_ioremap() devuelve NULL en caso de error. Actualmente, mt7996_mmio_wed_init() no verifica este caso, lo que resulta en una desreferencia de puntero NULL. Evitar la desreferencia de puntero NULL en mt7996_mmio_wed_init().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath9k_htc: Cancelar la gestión de balizas de software si está deshabilitada. Un dispositivo USB malicioso puede enviar un evento WMI_SWBA_EVENTID desde un dispositivo administrado por ath9k_htc antes de que se haya habilitado la baliza. Esto provoca un error de dispositivo por cero en el controlador, lo que provoca un bloqueo o una lectura fuera de los límites. Para evitarlo, cancele la gestión en ath9k_htc_swba() si las balizas no están habilitadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hisi_acc_vfio_pci: corrección del error de dirección dma de XQE Las direcciones dma de EQE y AEQE son incorrectas después de la migración, lo que provoca un fallo en los servicios de cifrado en modo kernel del invitado. Al comparar la definición de los registros de hardware, descubrimos que se producía un error al combinar los datos leídos del registro en una dirección. Por lo tanto, es necesario corregir la secuencia de combinación de direcciones. Incluso tras corregir el problema anterior, sigue existiendo un problema en el que el invitado de un kernel antiguo puede migrarse al nuevo, lo que puede generar datos erróneos. Para garantizar que la dirección sea correcta después de la migración, si se detecta un número mágico antiguo, es necesario actualizar la dirección dma.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Evite usar sk_socket después de liberar al enviar El sk->sk_socket no está bloqueado o referenciado en el hilo del backlog, y durante la llamada a skb_send_sock(), hay una condición de ejecución con la liberación de sk_socket. Todos los tipos de sockets (tcp/udp/unix/vsock) se verán afectados. Condiciones de ejecuciones: ''' CPU0 CPU1 backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ pánico aquí ''' La referencia de psock se convierte en 0 después de ejecutar sock_map_close(). ''' void sock_map_close() { ... if (likely(psock)) { ... // !! aquí eliminamos psock y la referencia de psock se convierte en 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== El control salta aquí mediante goto ... cancel_delayed_work_sync(&psock->work); <=== no se ejecuta sk_psock_put(sk, psock); ... } ''' Basándonos en el hecho de que ya esperamos a que finalice la cola de trabajo en sock_map_close() si psock está retenido, simplemente aumentamos el recuento de referencias de psock para evitar condiciones de ejecución. Con este parche, si el hilo de la lista de tareas pendientes se está ejecutando, sock_map_close() esperará a que se complete el hilo de la lista de tareas pendientes y cancelará todo el trabajo pendiente. Si no hay trabajos pendientes en ejecución, cualquier trabajo pendiente que no haya comenzado para entonces fallará al ser invocado por sk_psock_get(), ya que el recuento de referencias de psock se ha puesto a cero, y sk_psock_drop() cancelará todos los trabajos mediante cancel_delayed_work_sync(). En resumen, necesitamos sincronización para coordinar el hilo de trabajo pendiente y el hilo de cierre. El pánico que me entró: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: backlight: pm8941: Se ha añadido una comprobación de valores NULL en wled_configure(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, wled_configure() no realiza la comprobación en este caso, lo que provoca una desreferencia de puntero NULL. Se ha añadido una comprobación de valores NULL después de devm_kasprintf() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watchdog: lenovo_se30_wdt: Se corrige la posible desreferencia de puntero nulo de devm_ioremap() en lenovo_se30_wdt_probe(). Devm_ioremap() devuelve NULL en caso de error. Actualmente, lenovo_se30_wdt_probe() no comprueba este caso, lo que resulta en una desreferencia de puntero nulo. Agregue la comprobación de NULL después de devm_ioremap() para evitar este problema.