Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ieee802154/adf7242: aplazar la llamada a destroy_workqueue Existe una posible condición de ejecución (use-after-free) como la siguiente (FREE) | (USE) adf7242_remove | adf7242_channel cancel_delayed_work_sync | destroy_workqueue (1) | adf7242_cmd_rx | mod_delayed_work (2) | La causa raíz de esta ejecución es que la capa superior (ieee802154) desconoce este evento de desconexión y la función adf7242_channel se puede llamar sin ninguna comprobación. Para solucionar esto, podemos añadir una escritura de bandera al principio de adf7242_remove y añadir la comprobación de bandera en adf7242_channel. O podemos simplemente aplazar la operación destructiva como en el commit 3e0588c291d6 ("hamradio: defer ax25 kfree after unregister_netdev"), que permite que ieee802154_unregister_hw() gestione la sincronización. Este parche utiliza la segunda opción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: eliminar el subdesbordamiento de OPC antes de desactivar el reloj ODM [Por qué] Tras desactivar el reloj ODM, el bit de subdesbordamiento de OPC se mantendrá allí y la eliminación no funcionará. Necesitamos eliminarlo antes de desactivar el reloj. [Cómo] Eliminarlo si se produce al desactivar el reloj.

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: Se corrige una posible fuga de memoria en gpu_metrics_table. La memoria se asigna para gpu_metrics_table en smu_v13_0_4_init_smc_tables(), pero no se libera en smu_v13_0_4_fini_smc_tables(). Esto puede causar fugas de memoria; corríjalo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: corrige paquetes dañados para XDP_SHARED_UMEM Corrige un problema en el modo XDP_SHARED_UMEM junto con el modo alineado donde los paquetes se corrompen para el segundo socket y cualquier socket posterior vinculado al mismo umem. En otras palabras, esto no afecta al primer socket vinculado al umem. El culpable de este error es que la inicialización de las direcciones DMA para las entradas del grupo de búferes xsk pre-rellenadas no se realizó para ningún socket excepto el primero vinculado al umem. Solo se rellenó la matriz lineal de direcciones DMA. Corrige esto rellenando las direcciones DMA en el grupo de búferes xsk para cada socket vinculado al mismo umem.

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.