Vulnerabilidades

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: 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: 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: 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: 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: 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: firmware_loader: Se corrige el error "use-after-free" durante la anulación del registro. En el siguiente código, dentro de firmware_upload_unregister(), la llamada a device_unregister() podría provocar que la función dev_release libere la estructura fw_upload_priv antes de que se desreferenciara para la llamada a module_put(). Este error fue detectado por el robot de pruebas del kernel mediante CONFIG_KASAN al ejecutar las autopruebas del firmware. device_unregister(&fw_sysfs->dev); module_put(fw_upload_priv->module); El problema se corrige copiando fw_upload_priv->module a una variable local para su uso al llamar a device_unregister().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: corregir corrupción de memoria en la sonda Agregue la verificación de cordura faltante en el recuento de sesiones sondeadas para evitar corromper la memoria más allá de la matriz de sesiones asignadas por bloques de tamaño fijo cuando hay más de FASTRPC_MAX_SESSIONS sesiones definidas en el árbol de dispositivos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: cm3605: Se corrige una ruta de gestión de errores en cm3605_probe(). El commit en Fixes (correcciones) también introdujo una nueva ruta de gestión de errores que debería enlazar con la ruta de gestión de errores existente. De lo contrario, se producirían fugas de recursos.<br />

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: iforce - reactivar tras borrar el indicador IFORCE_XMIT_RUNNING. syzbot informa que la tarea está bloqueada en __input_unregister_device() [1], ya que iforce_close() espera en wait_event_interruptible() con dev-&amp;gt;mutex retenido, lo que bloquea input_disconnect_device() desde __input_unregister_device(). Parece que la causa es simplemente que el commit c2b27ef672992a20 ("Entrada: iforce - esperar a que se complete el comando al cerrar el dispositivo") olvidó llamar a wake_up() después de clear_bit(). Se soluciona este problema mediante un asistente que llame a clear_bit() seguido de wake_up_all().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/rtas: Corrección del manejo de MSR[HV] de RTAS para Cell. Los cambios recientes en el manejo de MSR al ingresar RTAS (firmware) provocan bloqueos en las máquinas IBM Cell. Ejemplo de rastreo: el kernel intentó ejecutar la página de usuario (2fff01a8): ¿intento de explotación? (uid: 0) ERROR: No se puede controlar la obtención de instrucciones del núcleo Dirección de instrucción errónea: 0x2fff01a8 Oops: Acceso del núcleo al área defectuosa, firma: 11 [#1] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 Módulos de celda NUMA vinculados: CPU: 0 PID: 0 Comm: swapper/0 Contaminado: GW 6.0.0-rc2-00433-gede0a8d3307a #207 NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 000000000000000 REGS: c0000000015236b0 TRAP: 0400 Contaminado: GW (6.0.0-rc2-00433-gede0a8d3307a) MSR: 0000000008001002 CR: 00000000 XER: 20000000 ... NIP 0x2fff01a8 LR 0x32608 Rastreo de llamadas: 0xc00000000143c5f8 (no confiable) .rtas_call+0x224/0x320 .rtas_get_boot_time+0x70/0x150 .read_persistent_clock64+0x114/0x140 .read_persistent_wall_and_boot_offset+0x24/0x80 .timekeeping_init+0x40/0x29c A diferencia de las plataformas PAPR, donde RTAS solo se usa en huéspedes, en las máquinas IBM Cell, Linux se ejecuta con MSR[HV] activado, pero también usa RTAS, proporcionado por SLOF. Para solucionarlo, copie el bit MSR[HV] del valor MSR que acabamos de leer con mfmsr al valor usado para RTAS. Parece que también podríamos solucionarlo usando un #ifdef CELL para activar MSR[HV], pero esto no funciona, ya que es posible crear una única imagen de kernel que funcione tanto en Cell nativo como en pseries.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kcm: corrección del orden y la limpieza de strp_init(). strp_init() se llama solo unas líneas por encima de la comprobación csk-&amp;gt;sk_user_data; también inicializa strp-&amp;gt;work, etc., por lo que no es necesario llamar a strp_done() para cancelar el trabajo recién inicializado. Si KCM ya utiliza sk_user_data, no se debe modificar psock-&amp;gt;strp, en particular el estado strp-&amp;gt;work, por lo que es necesario mover strp_init() después de la comprobación csk-&amp;gt;sk_user_data. Esto también elimina la advertencia de lockdep reportada por syzbot.