Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: skmsg: Corrige la última comprobación sg incorrecta en sk_msg_recvmsg() Corrige una desreferencia de puntero NULL del kernel como se muestra a continuación: [224.462334] Seguimiento de llamadas: [224.462394] __tcp_bpf_recvmsg+0xd3/0x380 [224.462441] ? syscall_trace_enter+0x1df/0x2e0 [ 224.462606] ? __do_page_fault+0x2de/0x500 [ 224.462635] __x64_sys_recvfrom+0x24/0x30 [ 224.462660] do_syscall_64+0x5d/0x1d0 [ 224.462709] entry_SYSCALL_64_after_hwframe+0x65/0xca En el commit 9974d37ea75f ("skmsg: Corregir la última comprobación de sg no válida en sk_msg_recvmsg()"), cambiamos la última comprobación de sg a sg_is_last(), pero en el caso de redirección de sockmap (sin stream_parser/stream_verdict/skb_verdict), no marcamos el final de la lista de dispersión. Verifique las funciones sk_msg_alloc, sk_msg_page_add y bpf_msg_push_data; ninguna marca el final de sg. Se espera que usen sg.end para la determinación del final. Por lo tanto, se añade aquí la determinación de '(i != msg_rx->sg.end)'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: Nintendo: corrección de la desreferencia del puntero nulo del trabajador de rumble. Podemos desreferenciar un puntero nulo que intenta poner en cola trabajo a una cola de trabajo destruida. Si el dispositivo se desconecta, se llama a nintendo_hid_remove, lo que destruye la cola de rumble. Evite usar esa cola para aplazar el trabajo de rumble una vez que el estado del mando se establezca en JOYCON_CTLR_STATE_REMOVED. Esto elimina la desreferencia del puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: No redirigir paquetes con pkt_len no válidos. Syzbot encontró un problema [1]: fq_codel_drop() intenta descartar un flujo sin skbs, es decir, el flujo->head es nulo. La causa principal, como se indica en [2], es que bpf_prog_test_run_skb() ejecuta un programa bpf que redirige skbs vacíos. Por lo tanto, debemos determinar si la longitud del paquete modificado por el programa bpf u otros como bpf_prog_test es válida antes de reenviarlo directamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: corrige fugas de referencia de netdevice en attached_default_qdiscs() En attached_default_qdiscs(), si un dev tiene varias colas y la cola 0 no puede adjuntar qdisc porque no hay memoria en attached_one_default_qdisc(). Entonces dev->qdisc será noop_qdisc por defecto. Pero las otras colas pueden ser capaces de adjuntar con éxito a la qdisc predeterminada. En este caso, se activará el proceso de retorno a noqueue. Si la qdisc adjunta original no se libera y se adjunta una nueva directamente, esto causará fugas de referencia de netdevice. El siguiente es el registro de errores: veth0: falla de qdisc predeterminada (fq_codel), retorno a noqueue unregister_netdevice: esperando a que veth0 se libere. Recuento de uso = 32 referencias filtradas. qdisc_alloc+0x12e/0x210 qdisc_create_dflt+0x62/0x140 attach_one_default_qdisc.constprop.41+0x44/0x70 dev_activate+0x128/0x290 __dev_open+0x12a/0x190 __dev_change_flags+0x1a2/0x1f0 dev_change_flags+0x23/0x60 do_setlink+0x332/0x1150 __rtnl_newlink+0x52f/0x8e0 rtnl_newlink+0x43/0x70 rtnetlink_rcv_msg+0x140/0x3b0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1bb/0x290 netlink_sendmsg+0x37c/0x4e0 sock_sendmsg+0x5f/0x70 ____sys_sendmsg+0x208/0x280 Corrija este error borrando cualquier qdisc que no sea noop que pueda haberse asignado antes de intentar volver a conectar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: openvswitch: se corrige una fuga de memoria al crear una ruta de datos fallida. ovs_dp_cmd_new()->ovs_dp_change()->ovs_dp_set_upcall_portids() asigna una matriz mediante kmalloc. Si por alguna razón new_vport() falla durante ovs_dp_cmd_new(), se debe liberar dp->upcall_portids. Se añade la falta de kfree. Ejemplo de Kmemleak: objeto sin referencia 0xffff88800c382500 (tamaño 64): comm "dump_state", pid 323, jiffies 4294955418 (edad 104.347s) volcado hexadecimal (primeros 32 bytes): 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8..... 03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(... backtrace: [<0000000071bebc9f>] ovs_dp_set_upcall_portids+0x38/0xa0 [<000000000187d8bd>] ovs_dp_change+0x63/0xe0 [<000000002397e446>] ovs_dp_cmd_new+0x1f0/0x380 [<00000000aa06f36e>] genl_family_rcv_msg_doit+0xea/0x150 [<000000008f583bc4>] genl_rcv_msg+0xdc/0x1e0 [<00000000fa10e377>] netlink_rcv_skb+0x50/0x100 [<000000004959cece>] genl_rcv+0x24/0x40 [<000000004699ac7f>] netlink_unicast+0x23e/0x360 [<00000000c153573e>] netlink_sendmsg+0x24e/0x4b0 [<000000006f4aa380>] sock_sendmsg+0x62/0x70 [<00000000d0068654>] ____sys_sendmsg+0x230/0x270 [<0000000012dacf7d>] ___sys_sendmsg+0x88/0xd0 [<0000000011776020>] __sys_sendmsg+0x59/0xa0 [<000000002e8f2dc1>] do_syscall_64+0x3b/0x90 [<000000003243e7cb>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915: se corrige la desreferencia de puntero nulo. La Chromebook Asus CX550 se bloquea durante el arranque en el kernel v5.17-rc1. La causa principal es la desreferencia de puntero nulo de bi_next en tgl_get_bw_info() en drivers/gpu/drm/i915/display/intel_bw.c. ERROR: desreferencia de puntero NULL del kernel, dirección: 000000000000002e PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 1 Comm: swapper/0 Contaminado: GU 5.17.0-rc1 Nombre del hardware: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 14/05/2021 RIP: 0010:tgl_get_bw_info+0x2de/0x510 ... [ 2.554467] Seguimiento de llamadas: [ 2.554467] [ 2.554467] intel_bw_init_hw+0x14a/0x434 [ 2.554467] ? _printk+0x59/0x73 [ 2.554467] ? _dev_err+0x77/0x91 [ 2.554467] i915_driver_hw_probe+0x329/0x33e [ 2.554467] i915_driver_probe+0x4c8/0x638 [ 2.554467] i915_pci_probe+0xf8/0x14e [ 2.554467] ? _raw_spin_unlock_irqrestore+0x12/0x2c [ 2.554467] pci_device_probe+0xaa/0x142 [ 2.554467] really_probe+0x13f/0x2f4 [ 2.554467] __driver_probe_device+0x9e/0xd3 [ 2.554467] driver_probe_device+0x24/0x7c [ 2.554467] __driver_attach+0xba/0xcf [ 2.554467] ? driver_attach+0x1f/0x1f [ 2.554467] bus_for_each_dev+0x8c/0xc0 [ 2.554467] bus_add_driver+0x11b/0x1f7 [ 2.554467] driver_register+0x60/0xea [ 2.554467] ? mipi_dsi_bus_init+0x16/0x16 [ 2.554467] i915_init+0x2c/0xb9 [ 2.554467] ? mipi_dsi_bus_init+0x16/0x16 [ 2.554467] do_one_initcall+0x12e/0x2b3 [ 2.554467] do_initcall_level+0xd6/0xf3 [ 2.554467] do_initcalls+0x4e/0x79 [ 2.554467] kernel_init_freeable+0xed/0x14d [ 2.554467] ? rest_init+0xc1/0xc1 [ 2.554467] kernel_init+0x1a/0x120 [ 2.554467] ret_from_fork+0x1f/0x30 [ 2.554467] ... Pánico del kernel - no sincroniza: Excepción fatal (seleccionada de el commit c247cd03898c4c43c3bce6d4014730403bc13032)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Hacer mark_chain_precision para ARG_CONST_ALLOC_SIZE_OR_ZERO Los marcadores de precisión deben propagarse siempre que tengamos un argumento de estilo ARG_CONST_*, ya que el verificador no puede considerar que los escalares imprecisos sean equivalentes para los fines de la comprobación states_equal cuando dichos argumentos refinan el valor de retorno (en este caso, establecer mem_size para PTR_TO_MEM). El mem_size resultante para el R0 se deriva del valor constante, y si el verificador poda incorrectamente los estados considerándolos equivalentes donde existen dichos argumentos (al ver que ambos registros tienen reg->precise como falso en regsafe), podemos terminar con programas no válidos que pasan el verificador que pueden hacer acceso más allá de lo que debería haber sido el mem_size correcto en ese estado explorado. Para mostrar un ejemplo concreto del problema: 0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: si r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: si w1 == 0 goto +1 10: r2 = -1 0000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: llamar a bpf_ringbuf_reserve 15: si r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: llamar a bpf_ringbuf_submit 00000000000000b8 : 23: w0 = 0 24: salir Para el primer caso, la exploración de la ejecución de una sola línea podará la búsqueda en insn 14 para la segunda rama de la rama insn 9, ya que se verificará primero utilizando r2 = -1 (UINT_MAX), mientras que como w1 en insn 9 siempre será 0, por lo que en tiempo de ejecución no obtenemos un error por ser mayor que UINT_MAX/4 de bpf_ringbuf_reserve. El verificador durante regsafe solo ve reg->precise como falso para ambos registros r2 en ambos estados, por lo tanto, los considera iguales para fines de states_equal. Si propagáramos marcadores precisos utilizando el soporte de retroceso, usaríamos el marcado preciso para asegurarnos de que el antiguo r2 (UINT_MAX) estuviera dentro del nuevo r2 (1) y esto nunca sería verdadero, por lo que la verificación fallaría legítimamente. El resultado final es que el acceso fuera de los límites en la instrucción 19 se permitiría sin esta corrección. Tenga en cuenta que reg->precise siempre se establece en verdadero cuando el usuario no tiene CAP_BPF (o cuando el recuento de subprocesos es mayor que 1 (es decir, uso de cualquier función estática o global)), por lo tanto, esto solo es un problema cuando las marcas de precisión deben propagarse explícitamente (es decir, usuarios privilegiados con CAP_BPF). Se ha incluido un caso de prueba simplificado en el próximo parche para evitar futuras regresiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: Se corrige la desreferencia de puntero nulo al eliminar si xHC solo tiene un concentrador raíz. La ruta de eliminación en el controlador de la plataforma xhci intenta eliminar e instalar los discos duros principal y compartido, incluso si solo existe un disco duro principal (un concentrador raíz). Esto provoca una desreferencia de puntero nulo al reiniciar esos controladores. Compruebe que el disco duro compartido exista antes de intentar eliminarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/ttm: corrección del manejo de CCS Crucible + Mesa reciente parece a veces afectar: GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER) Y parece que también podemos activar esto con gem_lmem_swapping, si modificamos la prueba para usar tamaños de objeto ligeramente mayores. Mirando más de cerca, parece que tenemos los siguientes problemas en migration_copy(): - Estamos usando un entero simple en varios lugares, que podemos desbordar fácilmente con un objeto grande. - Pasamos el tamaño completo del objeto (cuando el src es lmem) a emit_pte() y luego intentamos copiarlo, lo cual no funciona, ya que solo tenemos unas pocas ventanas de tamaño fijo en las que mapear las páginas y realizar la copia. Con un objeto > 8M, por lo tanto, no estamos copiando correctamente las páginas. Y luego, con un objeto > 64M, activamos GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER). Por lo tanto, parece que nuestra gestión de copias para cualquier objeto > 8M (que es nuestro CHUNK_SZ) está actualmente inactiva en DG2. Caso de prueba: igt@gem_lmem_swapping (seleccionado de el commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: cacheinfo: Se corrige la asignación incorrecta de un valor de error con signo a unsigned fw_level. Aunque acpi_find_last_cache_level() siempre devolvía un valor con signo y el documento indica que devolverá cualquier error causado por la falta de una tabla PPTT, nunca antes devolvía valores negativos. Sin embargo, el commit 0c80f9e165f8 ("ACPI: PPTT: Dejar la tabla asignada para el uso en tiempo de ejecución") la modificó devolviendo -ENOENT si no se encontraba PPTT. El valor devuelto por acpi_find_last_cache_level() se asigna entonces a unsigned fw_level. Esto provocará que el número de hojas de caché se calcule incorrectamente como un valor enorme, lo que provocará la siguiente advertencia de __alloc_pages, ya que el orden sería mayor que MAX_ORDER debido a un valor incorrecto y enorme de hojas de caché. ADVERTENCIA: CPU: 0 PID: 1 en mm/page_alloc.c:5407 __alloc_pages+0x74/0x314 | Módulos vinculados: | CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.19.0-10393-g7c2a8d3ac4c0 #73 | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __alloc_pages+0x74/0x314 | lr : alloc_pages+0xe8/0x318 | Rastreo de llamadas: | __alloc_pages+0x74/0x314 | alloc_pages+0xe8/0x318 | kmalloc_order_trace+0x68/0x1dc | Corrija el mismo problema cambiando fw_level para que sea un entero con signo y devuelva el error de init_cache_level() de manera temprana en caso de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: agregar interfaces ->fini_xxxx faltantes para algunos ASIC SMU13. Sin estas, se puede inducir una posible pérdida de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: agregar la interfaz ->fini_microcode faltante para Sienna Cichlid para evitar cualquier posible pérdida de memoria.