Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige una ejecución de datos en torno a bpf_jit_limit. Al leer bpf_jit_limit, se puede modificar simultáneamente mediante sysctl, WRITE_ONCE() en __do_proc_doulongvec_minmax(). El tamaño de bpf_jit_limit es grande, por lo que es necesario añadir un par de READ_ONCE() para evitar la fragmentación de la carga.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, cgroup: Se corrige el error del kernel en purge_effective_progs Syzkaller informó un error del kernel activado de la siguiente manera: ------------[ cortar aquí ]------------ ¡Error del kernel en kernel/bpf/cgroup.c:925! Código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 194 Comm: detach No contaminado 5.19.0-14184-g69dac8e431af #8 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0 Código: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84 28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 <0f> 0b 48 8b 0c5 RSP: 0018:ffffc9000055bdb0 EFLAGS: 00000246 RAX: 000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578 RBP: 000000000000000 R08: ffff888100ec0800 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000 R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00 FS: 00007f68213d2b80(0000) GS:ffff88813bc80000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0 Rastreo de llamadas: cgroup_bpf_prog_detach+0xcc/0x100 __sys_bpf+0x2273/0x2a00 __x64_sys_bpf+0x17/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f68214dbcb9 Código: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff8 RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007f68214dbcb9 RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009 RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003 R10: 00007ffeb487db70 R11: 0000000000000246 R12: 00007ffeb487dc20 R13: 000000000000004 R14: 000000000000001 R15: 000055f74a1011b0 Módulos vinculados en: ---[ fin del seguimiento 0000000000000000 ]--- Pasos de repetición: Para el siguiente árbol de cgroup, root | cg1 | cg2: 1. Adjuntar prog2 a cg2 y, a continuación, prog1 a cg1. El tipo de conexión de ambos programas bpf es NONE o OVERRIDE. 2. Escribir 1 en /proc/thread-self/fail-nth para failslab. 3. Desconectar prog1 de cg1 y, a continuación, se produce un error en el núcleo. La inyección de failslab provocará un fallo en kmalloc y volverá a purge_effective_progs. El problema radica en que cg2 ha adjuntado otro programa, por lo que, al pasar por la capa cg2, la iteración añadirá pos a 1, y las operaciones posteriores se omitirán por la siguiente condición, y cg cumplirá con NULL al final. `if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))` El cg NULL significa que no hay coincidencia de enlace o programa, esto es como se esperaba y no es un error. Por lo tanto, aquí simplemente omita la situación de no coincidencia.

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.

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: 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/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().