Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: corrige TASK_SIZE en NOMMU de 64 bits En NOMMU, la memoria del espacio de usuario puede provenir de cualquier lugar de la RAM física. La definición actual de TASK_SIZE es incorrecta si existe RAM por encima de 4G, lo que provoca fallos falsos en las rutinas de acceso al espacio de usuario.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bnxt_en: corrige una posible pérdida de memoria en bnxt_rdma_aux_device_init() Si ulp = kzalloc() falla, el edev asignado se perderá porque no está asignado correctamente y la ruta de limpieza no podrá liberarlo. Solucionarlo asignándolo correctamente inmediatamente después de la asignación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: geneve: corrige la validación del encabezado en geneve[6]_xmit_skb syzbot puede activar un valor uninit en geneve_xmit() [1] Problema: mientras que la mayoría de los asistentes de túnel IP (como ip_tunnel_get_dsfield( )) usa skb_protocol(skb, true), pskb_inet_may_pull() solo usa skb->protocol. Si se encuentra algo más que ETH_P_IPV6 o ETH_P_IP en skb->protocol, pskb_inet_may_pull() no hace nada en absoluto. Si la persona que llama proporcionó una etiqueta vlan (af_packet en el caso de syzbot), es posible que el encabezado de la red no apunte a la ubicación correcta y que la parte lineal de skb sea más pequeña de lo esperado. Agregue skb_vlan_inet_prepare() para realizar una validación completa de Mac. Utilice esto en Ginebra por el momento. Sospecho que debemos adoptarlo de manera más amplia. v4: Jakub informó que v3 rompió la autoprueba de l2_tos_ttl_inherit.sh: solo llame a __vlan_get_protocol() para tipos de VLAN. v2,v3: se abordaron los comentarios de Sabrina sobre v1 y v2 [1] ERROR: KMSAN: valor uninit en geneve_xmit_skb drivers/net/geneve.c:910 [en línea] ERROR: KMSAN: valor uninit en geneve_xmit+0x302d/0x5420 drivers/ net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [en línea] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [en línea] netdev_start_xmit include/ linux/netdevice.h:4917 [en línea] xmit_one net/core/dev.c:3531 [en línea] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c: 4335 dev_queue_xmit include/linux/netdevice.h:3091 [en línea] paquete_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 paquete_snd net/packet/af_packet.c:3081 [en línea] packet_sendmsg+0x8bb0/0x9ef0 net/packet/ af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [en línea ] __se_sys_sendto net/socket.c:2199 [en línea] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit se creó en slab_post_alloc _hook mm/slub.c:3804 [en línea] slab_alloc_node mm/slub.c:3845 [en línea] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c: 668 alloc_skb include/linux/skbuff.h:1318 [en línea] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 paquete_alloc_skb net/packet/af_packet.c :2930 [en línea] paquete_snd net/packet/af_packet.c:3024 [en línea] paquete_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x30f/0x380 net/ Socket.c: 745 __sys_sendto+0x685/0x830 net/Socket.c: 2191 __do_sys_sendto net/Socket.c: 2203 [en línea] __se_sys_sendto net/Socket.c: 2199 [Inline] __X64_SYS_SENDTO+0x125/0x1d0 net/Socket/Socket. 2199 do_syscall_64+0xd5/0x1f0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 0 PID: 5033 Comm: syz-executor346 No contaminado 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Nombre de hardware: Google Google Compute Engine/Google Motor de cómputo, BIOS Google 29/02/2024

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: octeontx2-pf: corrige la fuga de recursos del programador de transmisión. Para admitir la configuración y la programación, al crear la clase, el controlador Netdev asigna programadores de transmisión. El parche anterior que agregó soporte para la programación por turnos tiene un error debido a que el controlador no libera los programadores de transmisión después de la eliminación de la clase. Este parche soluciona lo mismo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: plataforma/chrome: cros_ec_uart: corrige correctamente la condición de ejecución. La función cros_ec_uart_probe() llama a devm_serdev_device_open() antes de llamar a serdev_device_set_client_ops(). Esto puede desencadenar una desreferencia del puntero NULL: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000... Seguimiento de llamadas: ...? ttyport_receive_buf Una versión simplificada del código de bloqueo es la siguiente: static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev; if (!serdev || !serdev->ops->receive_buf) // ¡CRASH! devolver 0; devolver serdev->ops->receive_buf(serdev, datos, recuento); } Se supone que si SERPORT_ACTIVE está configurado y serdev existe, serdev->ops también existirá. Esto entra en conflicto con la lógica cros_ec_uart_probe() existente, ya que primero llama a devm_serdev_device_open() (que configura SERPORT_ACTIVE), y solo luego configura serdev->ops a través de serdev_device_set_client_ops(). La confirmación 01f95d42b8f4 ("plataforma/chrome: cros_ec_uart: arreglar condición de ejecución") intentó arreglar una condición de ejecución similar, pero al hacerlo, hizo que la ventana de error para que esta condición de ejecución ocurriera fuera mucho más amplia. Intente corregir la condición de ejecución nuevamente, asegurándose de realizar la configuración completa antes de llamar a devm_serdev_device_open().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: corrija la pérdida de memoria en hci_req_sync_complete() En 'hci_req_sync_complete()', libere siempre el estado de solicitud de sincronización anterior antes de asignar una referencia a una nueva.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: raid1: corrige el uso después de liberar la biografía original en raid1_write_request() r1_bio->bios[] se usa para registrar nuevas biografías que se emitirán a los discos subyacentes; sin embargo, en raid1_write_request(), r1_bio->bios[] se configurará temporalmente en la biografía original. Mientras tanto, si se establece rdev bloqueado, se llamará a free_r1bio() causando que todos los r1_bio->bios[] sean liberados: raid1_write_request() r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] es NULL para (i = 0; i < discos; i++) -> para cada rdev en conf // el primer rdev es normal r1_bio->bios[0] = bio; -> establecer en biografía original // el segundo rdev está bloqueado si (test_bit(Blocked, &rdev->flags)) break if (blocked_rdev) free_r1bio() put_all_bios() bio_put(r1_bio->bios[0]) -> biografía original es Scripts de prueba liberados: mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs= 1 \ -io Depth=128 -name=test -direct=1 eco bloqueado > /sys/block/md0/md/rd2/state Resultado de la prueba: ERROR bio-264 (No contaminado): Objeto ya libre ------ -------------------------------------------------- --------------------- Asignado en mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869 kmem_cache_alloc+0x324/0x480 mempool_alloc_slab+0x24/0x50 mempool_alloc+0x6e /0x220 bio_alloc_bioset+0x1af/0x4d0 blkdev_direct_IO+0x164/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 io_submit_one+0x5ca/0xb70 __do_sys_io_submit+0x86/0x270 __x64_sys_io_submit+0x22/0x30 do_syscall_64+0xb1/0x210 Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Liberado en mempool_free_slab +0x1f/0x30 edad=1 cpu=1 pid=869 kmem_cache_free+0x28c/0x550 mempool_free_slab+0x1f/0x30 mempool_free+0x40/0x100 bio_free+0x59/0x80 bio_put+0xf0/0x220 free_r1bio+0x74/0xb0 raid1_make_ request+0xadf/0x1150 md_handle_request+ 0xc7/0x3b0 md_submit_bio+0x76/0x130 __submit_bio+0xd8/0x1d0 submit_bio_noacct_nocheck+0x1eb/0x5c0 submit_bio_noacct+0x169/0xd40 submit_bio+0xee/0x1d0 blkdev_direct_IO+0x322/0x8a0 _write_iter+0x309/0x440 aio_write+0x139/0x2f0 Dado que las BIOS para los discos subyacentes son aún no asignado, solucione este problema usando mempool_free() directamente para liberar r1_bio.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64: tlb: corrige el operando TLBI RANGE KVM/arm64 se basa en la función TLBI RANGE para vaciar los TLB cuando VMM recopila las páginas sucias y las entradas de la tabla de páginas quedan protegidas contra escritura durante la migración en vivo. . Desafortunadamente, el operando pasado a la instrucción TLBI RANGE no está ordenado correctamente debido a la confirmación 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()"). Esto provoca un bloqueo en la máquina virtual de destino después de la migración en vivo porque los TLB no se vacían por completo y se omiten algunas de las páginas sucias. Por ejemplo, tengo una máquina virtual a la que se asignan 8 GB de memoria, a partir de 0x40000000 (1 GB). Tenga en cuenta que el host tiene 4 KB como tamaño de página base. En medio de la migración, se ejecuta kvm_tlb_flush_vmid_range() para vaciar los TLB. Pasa MAX_TLBI_RANGE_PAGES como argumento para __kvm_tlb_flush_vmid_range() y __flush_s2_tlb_range_op(). SCALE#3 y NUM#31, correspondientes a MAX_TLBI_RANGE_PAGES, no son compatibles con __TLBI_RANGE_NUM(). En este caso específico, -1 ha sido devuelto por __TLBI_RANGE_NUM() para SCALE#3/2/1/0 y rechazado por el bucle en __flush_tlb_range_op() hasta que la variable @scale se desborda por debajo y se convierte en -9, 0xffff708000040000 se establece como el operando. El operando es incorrecto ya que __TLBI_VADDR_RANGE() lo ordena según @scale y @num no válidos. Solucionelo extendiendo __TLBI_RANGE_NUM() para admitir la combinación de SCALE#3 y NUM#31. Con los cambios, [-1 31] en lugar de [-1 30] se puede devolver desde la macro, lo que significa que los TLB para páginas 0x200000 en el ejemplo anterior se pueden vaciar de una vez con ESCALA#3 y NUM#31. La macro TLBI_RANGE_MASK se elimina porque ya nadie la usa. Los comentarios también se adaptan en consecuencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_net: no enviar clave RSS si no es compatible. Hay un error al configurar las opciones de RSS en virtio_net que puede dañar toda la máquina, haciendo que el kernel entre en un bucle infinito. Ejecutar el siguiente comando en cualquier máquina virtual QEMU con virtionet reproducirá este problema: # ethtool -X eth0 hfunc toeplitz Así es como ocurre el problema: 1) ethtool_set_rxfh() llama a virtnet_set_rxfh() 2) virtnet_set_rxfh() llama a virtnet_commit_rss_command() 3) virtnet_commit_rss_command() completa 4 entradas para rss scatter-gather 4) Dado que el comando anterior no tiene una clave, la última entrada de scatter-gatter se pondrá a cero, ya que rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) Este búfer se pasa a qemu, pero qemu no está contento con un búfer con longitud cero, y haga lo siguiente en virtqueue_map_desc() (función QEMU): if (!sz) { virtio_error(vdev, "virtio: buffers de tamaño cero no están permitidos"); 6) virtio_error() (también función QEMU) configura el dispositivo como roto vdev->broken = true; 7) Qemu se retira y no responde a este kernel loco. 8) El kernel está esperando a que regrese la respuesta (función virtnet_send_command()) 9) El kernel está esperando haciendo lo siguiente: while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) Ninguna de las siguientes funciones anteriores es verdadera, por lo tanto, el núcleo se repite aquí para siempre. Teniendo en cuenta que virtqueue_is_broken() no mira el qemu `vdev->broken`, por lo tanto, nunca se da cuenta de que el vitio está roto en el lado de QEMU. Solucionelo no enviando comandos RSS si la función no está disponible en el dispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: batman-adv: Evite el bucle infinito al intentar cambiar el tamaño del TT local. Si la MTU de una de las interfaces conectadas se vuelve demasiado pequeña para transmitir la tabla de traducción local, entonces se debe cambiar su tamaño para que quepa dentro. todos los fragmentos (cuando está habilitado) o un solo paquete. Pero si la MTU es demasiado baja para transmitir incluso el encabezado + la parte específica de la VLAN, entonces el cambio de tamaño del TT local nunca tendrá éxito. Esto puede suceder, por ejemplo, cuando el espacio utilizable es de 110 bytes y hay 11 VLAN encima de batman-adv. En este caso, se necesitarían al menos 116 bytes. Simplemente habrá un spam interminable de batman_adv: batadv0: Obligado a purgar las entradas tt locales para ajustar el nuevo fragmento máximo MTU (110) en el registro, pero la función nunca finalizará. El problema aquí es que el tiempo de espera se reducirá a la mitad todo el tiempo y luego se estancará en 0 y, por lo tanto, nunca podrá reducir la tabla aún más. Hay otros escenarios posibles con un resultado similar. El número de entradas BATADV_TT_CLIENT_NOPURGE en el TT local puede, por ejemplo, ser demasiado alto para caber dentro de un paquete. Por lo tanto, este escenario puede ocurrir también con una sola VLAN + 7 direcciones no purgables, lo que requiere al menos 120 bytes. Si bien esto debe manejarse de manera proactiva cuando: * se agrega una interfaz con una MTU demasiado baja * se agrega una VLAN * se agrega una mac local no purgable * se reduce la MTU de una interfaz conectada * la configuración de fragmentación se desactiva (lo que probablemente requiera eliminar las interfaces conectadas) No todos estos escenarios se pueden prevenir porque batman-adv solo consume eventos sin la posibilidad de evitar estas acciones (se agrega una dirección MAC no purgable, se reduce la MTU de una interfaz adjunta). Por lo tanto, también es necesario asegurarse de que el código sea capaz de manejar también las situaciones en las que ya había una configuración del sistema incompatible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: límites: utilice el número correcto de bits para potencia de dos CONFIG_NR_CPUS bits_per() redondea a la siguiente potencia de dos cuando se pasa una potencia de dos. Esto provoca fallos en algunas máquinas y configuraciones.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: smbus: corrige la desreferencia del puntero de función NULL. Baruch informó de un OOPS al usar el controlador de designware como destino únicamente. Los modos de solo objetivo rompen el supuesto de que siempre hay una función de transferencia disponible. Solucione este problema comprobando siempre el puntero en __i2c_transfer. [wsa: abandonó la simplificación en core-smbus para evitar regresiones teóricas]