Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige slab-out-of-bounds en smb2_allocate_rsp_buf Si ->ProtocolId es SMB2_TRANSFORM_PROTO_NUM, se podría omitir la validación del tamaño de la solicitud smb2. Si el tamaño de la solicitud es menor que sizeof (struct smb2_query_info_req), la lectura de losa fuera de los límites puede ocurrir en smb2_allocate_rsp_buf(). Este parche asigna un búfer de respuesta después de descifrar la solicitud de transformación. smb3_decrypt_req() validará el tamaño de la solicitud de transformación y evitará la losa fuera de los límites en smb2_allocate_rsp_buf().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige OOB en nilfs_set_de_type El tamaño de la matriz nilfs_type_by_mode en el archivo fs/nilfs2/dir.c se define como "S_IFMT >> S_SHIFT", pero la función nilfs_set_de_type() , que utiliza esta matriz, especifica el índice a leer de la matriz de la misma manera que "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t modo = inodo->i_mode; de->tipo_archivo = nilfs_type_by_mode[(modo & S_IFMT)>>S_SHIFT]; // oob } Sin embargo, cuando el índice se determina de esta manera, se produce un error fuera de los límites (OOB) al hacer referencia a un índice que es 1 mayor que el tamaño de la matriz cuando la condición "modo & S_IFMT == S_IFMT" es satisfecho. Por lo tanto, se debe aplicar un parche para cambiar el tamaño de la matriz nilfs_type_by_mode para evitar errores OOB.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: Squashfs: comprobar que el número de inodo no sea el valor no válido de cero. Syskiller ha producido un acceso fuera de los límites en fill_meta_index(). Ese acceso fuera de los límites se debe en última instancia a que el inodo tiene un número de inodo con un valor no válido de cero, que no se verificó. La razón por la que esto causa el acceso fuera de los límites se debe a la siguiente secuencia de eventos: 1. Se llama a Fill_meta_index() para asignar (a través de vacío_meta_index()) y completar un índice de metadatos. Sin embargo, sufre un error de lectura de datos y se cancela, invalidando el índice de metadatos vacío recién devuelto. Para ello, establece el número de inodo del índice en cero, lo que significa que no se utiliza (cero no es un número de inodo válido). 2. Cuando posteriormente se vuelve a llamar a fill_meta_index() en otra operación de lectura, localizar_meta_index() devuelve el índice anterior porque coincide con el número de inodo de 0. Debido a que este índice ha sido devuelto, se espera que se haya completado, y porque no lo ha hecho. Si no lo ha sido, se realiza un acceso fuera de los límites. Este parche agrega una verificación de cordura que verifica que el número de inodo no sea cero cuando se crea el inodo y devuelve -EINVAL si lo es. [phillip@squashfs.org.uk: corrección de espacios en blanco] Enlace: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bootconfig: use memblock_free_late para liberar memoria xbc para el amigo En el momento de liberar memoria xbc en xbc_exit(), es posible que memblock haya entregado la memoria al asignador de amigos. Por lo tanto, no tiene sentido liberar memoria en Memblock. memblock_free() llamado por xbc_exit() incluso causa errores UAF en arquitecturas con CONFIG_ARCH_KEEP_MEMBLOCK deshabilitado como x86. Los siguientes registros de KASAN muestran este caso. Este parche soluciona el problema de falta de memoria de xbc llamando a memblock_free() en la ruta de rebobinado del error de inicio temprano de xbc y llamando a memblock_free_late() en la ruta de salida de xbc para liberar memoria al asignador de amigos. [9.410890] ================================================= =================== [9.418962] ERROR: KASAN: use-after-free en memblock_isolate_range+0x12d/0x260 [9.426850] Lectura de tamaño 8 en la dirección ffff88845dd30000 por el intercambiador de tareas /0/1 [ 9.435901] CPU: 9 PID: 1 Comm: swapper/0 Contaminado: GU 6.9.0-rc3-00208-g586b5dfb51b9 #5 [ 9.446403] Nombre de hardware: Intel Corporation RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 28 de diciembre de 2023 [9.460789] Seguimiento de llamadas: [9.463518] [9.465859] dump_stack_lvl+0x53/0x70 [9.469949] puerto+0xce/0x610 [ 9.473944] ? __virt_addr_valid+0xf5/0x1b0 [9.478619]? memblock_isolate_range+0x12d/0x260 [ 9.483877] kasan_report+0xc6/0x100 [ 9.487870] ? memblock_isolate_range+0x12d/0x260 [9.493125] memblock_isolate_range+0x12d/0x260 [9.498187] memblock_phys_free+0xb4/0x160 [9.502762]? __pfx_memblock_phys_free+0x10/0x10 [9.508021]? mutex_unlock+0x7e/0xd0 [9.512111]? __pfx_mutex_unlock+0x10/0x10 [9.516786]? kernel_init_freeable+0x2d4/0x430 [9.521850]? __pfx_kernel_init+0x10/0x10 [ 9.526426] xbc_exit+0x17/0x70 [ 9.529935] kernel_init+0x38/0x1e0 [ 9.533829] ? _raw_spin_unlock_irq+0xd/0x30 [9.538601] ret_from_fork+0x2c/0x50 [9.542596]? __pfx_kernel_init+0x10/0x10 [ 9.547170] ret_from_fork_asm+0x1a/0x30 [ 9.551552] [ 9.555649] La dirección con errores pertenece a la página física: [ 9.561875] página: refcount:0 mapcount:0 mapeo:00000000000 Índice 00000: 0x1 pfn :0x45dd30 [ 9.570821] banderas: 0x200000000000000(nodo=0|zona=2) [ 9.576271] tipo de página: 0xffffffff() [ 9.580167] raw: 0200000000000000 ffffea0011774c48 12ba1848 0000000000000000 [9.588823] raw: 0000000000000001 0000000000000000 00000000ffffffff 000000000000000000000000 [9.597476] página volcada porque: kasan: mal acceso detectado [9.605362] Estado de la memoria alrededor de la dirección con errores: [9.610714] ffff88845dd2ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 9.618786] ffff88845dd2ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 9.626857] >ffff88845dd30000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.634930] ^ [ 9.638534] ffff88845dd30080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.646605] ffff88845dd30100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.654675] ======================= ===============================================

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nouveau: corrige la condición de ejecución de instmem alrededor de las tiendas ptr Al ejecutar una gran cantidad de VK CTS en paralelo contra nouveau, una vez cada pocas horas es posible que vea algo como este bloqueo. ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Ups: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk No contaminado 6.8.0-rc6+ #27 Nombre del hardware : Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 05/11/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nuevo] Código: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 0 0 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) nlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nuevo]? gp100_vmm_pgt_mem+0x37/0x180 [nuevo] nvkm_vmm_iter+0x351/0xa20 [nuevo] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nuevo] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nuevo] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nuevo] ? __lock_acquire+0x3ed/0x2170? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nuevo] nvkm_vmm_ptes_get_map+0xc2/0x100 [nuevo] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nuevo] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nuevo] nvkm_vmm_map_locked+0x224/0x3a0 [nuevo] Agregar cualquier tipo de depuración útil generalmente hace que desaparezca, así que escribí la función a mano en una línea y depuré el asm. De vez en cuando pt->memoria->ptrs es NULL. Este ptrs ptr se establece en nv50_instobj_acquire llamado desde nvkm_kmap. Si el subproceso A y el subproceso B llegan a nv50_instobj_acquire aproximadamente al mismo tiempo, y el subproceso A llega a la línea refcount_set, y en paralelo el subproceso B tiene éxito en refcount_inc_not_zero, existe la posibilidad de que el valor de ptrs no se haya almacenado ya que refcount_set no está ordenado. Forzar una barrera de memoria aquí, elegí smp_mb, ya que lo queremos en todas las CPU y es escritura seguida de lectura. v2: use smp_rmb/smp_wmb emparejado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: qat: resuelve la condición de ejecución durante la recuperación de AER Durante el proceso de recuperación de errores del sistema PCI AER, el controlador del kernel puede encontrar una condición de ejecución al liberar la memoria de la estructura reset_data. Si el reinicio del dispositivo demora más de 10 segundos, la función que programa el reinicio se cerrará debido a un tiempo de espera y se liberará la estructura reset_data. Sin embargo, esta estructura de datos se utiliza para la notificación de finalización después de que se completa el reinicio, lo que genera un error de UAF. Esto da como resultado un aviso de error de KFENCE. ERROR: KFENCE: lectura de uso después de liberación en adf_device_reset_worker+0x38/0xa0 [intel_qat] Lectura de uso después de liberación en 0x00000000bc56fddf (en kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] Process_one_work+0x173/0x340 Para resolver En esta condición de ejecución, la memoria asociada al contenedor de work_struct se libera en el trabajador si el tiempo de espera expiró; en caso contrario, en la función que programa al trabajador. La detección del tiempo de espera se puede realizar comprobando si la persona que llama todavía está esperando que finalice o no mediante la función complete_done().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powercap: intel_rapl: corrige una desreferencia de puntero NULL Se activa una desreferencia de puntero NULL al probar el controlador MMIO RAPL en plataformas con ID de CPU que no figuran en la lista de modelos de CPU intel_rapl_common. Esto se debe a que el módulo intel_rapl_common aún sondea en dichas plataformas incluso si 'defaults_msr' no está configurado después de confirmar 1488ac990ac8 ("powercap: intel_rapl: Permitir sondeo sin coincidencia de CPUID"). Por lo tanto, MMIO RAPL rp->priv->defaults es NULL cuando se registra en el marco RAPL. Solucione el problema agregando una verificación de cordura para garantizar que rp->priv->rapl_defaults siempre sea válido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: siempre vacíe la cola de trabajo asíncrona #PF cuando se destruya la vCPU. Siempre vacíe la cola de trabajo asíncrona #PF por vCPU cuando una vCPU esté limpiando su cola de finalización, por ejemplo, cuando una VM y todo sus vCPU están siendo destruidas. KVM debe asegurarse de que ninguna de sus devoluciones de llamada de la cola de trabajo se esté ejecutando cuando se coloca la última referencia al _módulo_ KVM. Regalar una referencia a la VM asociada evita que la devolución de llamada de la cola de trabajo elimine la referencia a la memoria de vCPU/VM liberada, pero no evita que el módulo KVM se descargue antes de que se complete la devolución de llamada. Elimine el regalo de recuento de VM equivocado, ya que llamar a kvm_put_kvm() desde async_pf_execute() si kvm_put_kvm() vacía la cola de trabajo asíncrona #PF resultará en un punto muerto. async_pf_execute() no puede regresar hasta que finalice kvm_put_kvm(), y kvm_put_kvm() no puede regresar hasta que finalice async_pf_execute(): ADVERTENCIA: CPU: 8 PID: 251 en virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Módulos vinculados en: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: GW 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Nombre de hardware: Estándar QEMU PC (Q35 + ICH9, 2009), BIOS 0.0.0 06/02/2015 Cola de trabajo: eventos async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Seguimiento de llamadas: async_pf_execute+0x198/0x260 [kvm ] Process_one_work+0x145/0x2d0 work_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 ---[ end trace 0000000000000000 ]--- INFORMACIÓN: tarea kworker /8:1: 251 bloqueado durante más de 120 segundos. Contaminado: GW 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:kworker/8:1 estado:D pila:0 pid:251 ppid:2 banderas:0x00004000 Cola de trabajo: eventos async_pf_execute [kvm] Seguimiento de llamadas: __schedule+0x33f/0xa40 Schedule+0x53/0xc0 Schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] x320 [kvm] async_pf_execute+0x198/0x260 [kvm] proceso_one_work+0x145/ 0x2d0 trabajador_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 Si kvm_clear_async_pf_completion_queue() realmente vacía la cola de trabajo, entonces no hay necesidad de regalar un referencia porque todas las invocaciones de async_pf_execute () se verá obligado a completarse antes de que la vCPU y su VM sean destruidas o liberadas. Y eso, a su vez, corrige el error de descarga del módulo, ya que __fput() no ejecutará module_put() en la última referencia de vCPU hasta que se haya liberado la vCPU, por ejemplo, si al cerrar el archivo de vCPU también se coloca la última referencia al módulo KVM. Tenga en cuenta que kvm_check_async_pf_completion() también puede sacar el elemento de trabajo de la cola de finalización y, por lo tanto, también necesita vaciar la cola de trabajos, ya que kvm_clear_async_pf_completion_queue() no verá el trabajo. En teoría, esperar en la cola de trabajo podría retrasar una vCPU debido a la espera de que se complete el trabajo, pero esa es una posibilidad muy, muy pequeña y probablemente un retraso muy pequeño. kvm_arch_async_page_present_queued() realiza incondicionalmente una nueva solicitud, es decir, efectivamente retrasará la entrada del invitado, por lo que el trabajo restante es realmente solo: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); y mmput() no puede eliminar la última referencia a las tablas de páginas si la vCPU aún está activa, es decir, la vCPU no se atascará al derribar las tablas de páginas. ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: pci_iounmap(): corrige la fuga de mapeo MMIO El #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentalmente también protege iounmap(), lo que significa que se filtraron los mapeos MMIO. Mueva la guardia para que llamemos a iounmap() para asignaciones MMIO.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: camcc-sc8280xp: corrección de terminación de matrices de tablas de frecuencia Se supone que las matrices de tablas de frecuencia terminan con un elemento vacío. Agregue dicha entrada al final de las matrices donde falta para evitar un posible acceso fuera de los límites cuando la tabla es atravesada por funciones como qcom_find_freq() o qcom_find_freq_floor(). Solo compilar probado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: gcc-ipq9574: corrección de terminación de matrices de tablas de frecuencia Se supone que las matrices de tablas de frecuencia terminan con un elemento vacío. Agregue dicha entrada al final de las matrices donde falta para evitar un posible acceso fuera de los límites cuando la tabla es atravesada por funciones como qcom_find_freq() o qcom_find_freq_floor(). Solo compilar probado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: gcc-ipq8074: corrección de terminación de matrices de tablas de frecuencia Se supone que las matrices de tablas de frecuencia terminan con un elemento vacío. Agregue dicha entrada al final de las matrices donde falta para evitar un posible acceso fuera de los límites cuando la tabla es atravesada por funciones como qcom_find_freq() o qcom_find_freq_floor(). Solo compilar probado.