Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio/vsock: Mejorar el manejo de errores MSG_ZEROCOPY. Agregar un kfree_skb() faltante para evitar pérdidas de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: se corrige la pérdida de memoria sk_error_queue. El kernel coloca en cola las notificaciones de finalización MSG_ZEROCOPY en la cola de errores, donde permanecen hasta que se recv()en forma explícita. Para evitar pérdidas de memoria, limpie la cola cuando se destruya el socket. objeto sin referencia 0xffff8881028beb00 (tamaño 224): comm "vsock_test", pid 1218, jiffies 4294694897 volcado hexadecimal (primeros 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: corregir la desreferencia de puntero NULL en alloc_pages_bulk_noprof Activamos una desreferencia de puntero NULL para ac.preferred_zoneref->zone en alloc_pages_bulk_noprof() cuando la tarea se migra entre conjuntos de CPU. Cuando se habilita el conjunto de CPU, en prepare_alloc_pages(), ac->nodemask puede ser &current->mems_allowed. Cuando se llama a first_zones_zonelist() para encontrar preference_zoneref, ac->nodemask puede modificarse simultáneamente si la tarea se migra entre diferentes conjuntos de CPU. Suponiendo que tenemos 2 nodos NUMA, al recorrer el nodo 1 en ac->zonelist, la máscara de nodo es 2, y al recorrer el nodo 2 en ac->zonelist, la máscara de nodo es 1. Como resultado, ac->preferred_zoneref apunta a la zona NULL. En alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() encuentra una zona permitida y llama a zonelist_node_idx(ac.preferred_zoneref), lo que genera una desreferencia del puntero NULL. __alloc_pages_noprof() corrige este problema al verificar el puntero NULL en el commit ea57485af8f4 ("mm, page_alloc: corregir la verificación para la zona preferida NULL") y el commit df76cee6bbeb ("mm, page_alloc: eliminar las verificaciones redundantes de la ruta rápida de asignación"). Para solucionarlo, verifique el puntero NULL para la zona preferida->zone.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio/vsock: Se soluciona la pérdida de memoria de accept_queue. Como las etapas finales de la destrucción del socket pueden demorarse, es posible que se llame a virtio_transport_recv_listen() después de que se haya vaciado accept_queue, pero antes de que se haya establecido el indicador SOCK_DONE. Como resultado, los sockets en cola después del vaciado permanecerían sin eliminar, lo que provocaría una pérdida de memoria. vsock_release __vsock_release bloquear virtio_transport_release virtio_transport_close schedule_delayed_work(cerrar_trabajo) sk_shutdown = SHUTDOWN_MASK (!) vaciar accept_queue liberar virtio_transport_recv_pkt vsock_find_bound_socket bloquear si indicador(SOCK_DONE) devolver virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) liberar close_work bloquear virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound liberar Introduce una comprobación de sk_shutdown para no permitir vsock_enqueue_accept() durante la destrucción del socket. objeto sin referencia 0xffff888109e3f800 (tamaño 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] subproceso_trabajador+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_de_la_bifurcación+0x2d/0x50 [] ret_de_la_bifurcación_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: CT: Corregir null-ptr-deref en el flujo de error de agregar regla. En el flujo de error de mlx5_tc_ct_entry_add_rule(), en caso de que la devolución de llamada ct_rule_add() devuelva un error, se usa zone_rule->attr sin iniciar. Arréglelo para usar attr que tiene el valor de puntero necesario. Registro del kernel: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Seguimiento de llamadas: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: fs, bloquear FTE al verificar si está activo Las confirmaciones a las que se hace referencia introdujeron un proceso de dos pasos para eliminar FTE: - Bloquear el FTE, eliminarlo del hardware, establecer la función de eliminación de hardware en NULL y desbloquear el FTE. - Bloquear el grupo de flujo principal, eliminar la copia de software del FTE y eliminarlo de la matriz x. Sin embargo, este enfoque encuentra una condición de carrera si se agrega simultáneamente una regla con el mismo valor de coincidencia. En este escenario, fs_core puede establecer la función de eliminación de hardware en NULL de forma prematura, lo que provoca un pánico durante las eliminaciones de reglas posteriores. Para evitar esto, asegúrese de que el indicador activo del FTE esté marcado bajo un bloqueo, lo que evitará que la capa fs_core adjunte una nueva regla de dirección a un FTE que esté en proceso de eliminación. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cortar aquí ]------------ [ 438.968654] refcount_t: el decremento llegó a 0; pérdida de memoria. [ 438.969249] ADVERTENCIA: CPU: 0 PID: 8957 en lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Módulos vinculados en: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry superposición rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [última descarga: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc No contaminado 6.12.0-rc1+ #8 [ 438.973888] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Código: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 00000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Seguimiento de llamadas: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [438.994728] tc_setup_cb_destroy+0xb9/0x190 [438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncado---

La vulnerabilidad de neutralización incorrecta de la entrada durante la generación de páginas web ('Cross-site Scripting') en Imbasynergy ImbaChat permite XSS basado en DOM. Este problema afecta a ImbaChat: desde n/a hasta 3.1.4.

La vulnerabilidad de neutralización incorrecta de la entrada durante la generación de páginas web ('Cross-site Scripting') en Tailored Web Services Tailored Tools permite XSS almacenado. Este problema afecta a Tailored Tools: desde n/a hasta 1.8.4.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc/task_mmu: evitar el desbordamiento de enteros en pagemap_scan_get_args() La variable "arg->vec_len" es una u64 que proviene del usuario al inicio de la función. La multiplicación "arg->vec_len * sizeof(struct page_region))" puede provocar un ajuste de enteros. Utilice size_mul() para evitarlo. Además, las funciones size_add/mul() funcionan en unsigned long, por lo que para los sistemas de 32 bits debemos asegurarnos de que "arg->vec_len" quepa en un unsigned long.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Ajustar el analizador VSDB para la función de reproducción En algún momento, se agregó la identificación IEEE ID para la comprobación de reproducción en AMD EDID. Sin embargo, esta comprobación provoca los siguientes problemas fuera de los límites al utilizar KASAN: [ 27.804016] ERROR: KASAN: slab-out-of-bounds en amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Lectura de tamaño 1 en la dirección ffff8881647fdb00 por la tarea systemd-udevd/383 ... [ 27.821207] Estado de la memoria alrededor de la dirección con errores: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ===================================================================== Esto se debe a que la extracción de ID se realiza fuera del rango de longitud de edid. Esta confirmación soluciona este problema al considerar el tamaño de amd_vsdb_block. (seleccionado de el commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nommu: pasar argumento NULL a vma_iter_prealloc(). Al eliminar una entrada vma de un árbol maple, tiene que pasar NULL a vma_iter_prealloc() para calcular el estado interno del árbol, pero pasó un argumento incorrecto. Como resultado, los kernels nommu fallaban al acceder a un iterador vma, como acct_collect() que lee el tamaño de las entradas vma después de do_munmap(). Esta confirmación corrige este problema al pasar un argumento correcto a la llamada de preasignación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mremap: se corrige el envoltorio de direcciones en move_page_tables() En plataformas de 32 bits, es posible que la expresión `len + old_addr < old_end` sea un falso positivo si `len + old_addr` realiza un envoltorio. `old_addr` es el cursor en el rango antiguo hasta el cual se han movido las entradas de la tabla de páginas; por lo que si la operación tuvo éxito, `old_addr` es el *final* de la región antigua, y agregarle `len` puede realizar un envoltorio. El desbordamiento hace que mremap() crea erróneamente que se han copiado las PTE; la consecuencia es que mremap() se retira, pero no mueve las PTE de nuevo antes de que se desasigne el nuevo VMA, lo que provoca que se pierdan las páginas anónimas en la región. Básicamente, si el espacio de usuario intenta ejecutar mremap() en una región privada-anon y encuentra este error, mremap() devolverá un error y el contenido de la región privada-anon parecerá haber sido puesto a cero. La idea de esta comprobación es que `old_end - len` sea la dirección de inicio original, y escribir la comprobación de esa manera también facilita la lectura; por lo tanto, arregle la comprobación reorganizando la comparación en consecuencia. (Un workaround sería refactorizar esta función introduciendo una variable "orig_old_start" o algo similar). Probado en una máquina virtual con un núcleo X86 de 32 bits; sin el parche: ``` usuario@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, "mmap 1"); carácter sin signo *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); si (p2 == MAP_FAILED) err(1, "mmap 2"); *p1 = 0x41; printf("el primer carácter es 0x%02hhx\n", *p1); carácter sin signo *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); si (p3 == MAP_FAILED) { printf("mremap() falló; el primer carácter es 0x%02hhx\n", *p1); } de lo contrario { printf("mremap() tuvo éxito; el primer carácter es 0x%02hhx\n", *p3); } } usuario@horn:~/big_mremap$ gcc -static -o test test.c usuario@horn:~/big_mremap$ setarch -R ./test el primer carácter es 0x41 mremap() falló; el primer carácter es 0x00 ``` Con el parche: ``` usuario@horn:~/big_mremap$ setarch -R ./test el primer carácter es 0x41 mremap() tuvo éxito; el primer carácter es 0x41 ```