Vulnerabilidades

Vulnerabilidad de ejecución remota de código de desbordamiento de búfer en la región stack de la memoria de análisis de archivos TIF de Kofax Power PDF. Esta vulnerabilidad permite a atacantes remotos ejecutar código arbitrario en instalaciones afectadas de Kofax Power PDF. Se requiere la interacción del usuario para aprovechar esta vulnerabilidad, ya que el objetivo debe visitar una página maliciosa o abrir un archivo malicioso. La falla específica existe en el análisis de archivos TIF. El problema se debe a la falta de una validación adecuada de la longitud de los datos proporcionados por el usuario antes de copiarlos en un búfer en la región stack de la memoria de longitud fija. Un atacante puede aprovechar esta vulnerabilidad para ejecutar código en el contexto del proceso actual. Era ZDI-CAN-22033.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: gtp: corrige use-after-free y null-ptr-deref en gtp_genl_dump_pdp() La estructura de operaciones pernet gtp_net_ops para el subSYSTEM debe registrarse antes de registrar la familia netlink genérica. Syzkaller encontró el error 'fallo de protección general en gtp_genl_dump_pdp': fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000010-0x00000000000000 017] CPU: 1 PID : 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 01/04/2014 RIP: 0010:gtp_genl_dump_pdp +0x1be/0x800 [gtp] Código: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 e un 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX : 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000000 R11: 0000000000000000 R12 : 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) kn lGS:0000000000000000 CS: 0010 DS: 0000 ES : 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Seguimiento de llamadas: ? show_regs+0x90/0xa0? die_addr+0x50/0xd0? exc_general_protection+0x148/0x220? asm_exc_general_protection+0x22/0x30? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430? __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440? cap_capaz+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? seguridad_capaz+0x9d/0xe0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No suspender la matriz por remodelación interrumpida md_start_sync() suspenderá la matriz si hay repuestos que se pueden agregar o eliminar de conf, sin embargo, si la remodelación aún está en marcha progreso, esto no sucederá en absoluto o los datos se dañarán (no se llamará a remove_and_add_spares desde md_choose_sync_action para remodelar), por lo tanto, no hay necesidad de suspender la matriz si la remodelación aún no se ha realizado. Mientras tanto, existe un posible punto muerto para raid456: 1) se interrumpe la remodelación; 2) configure uno de los discos WantReplacement y agregue un nuevo disco a la matriz; sin embargo, la recuperación no comenzará hasta que finalice la remodelación; 3) luego emita una IO a través de la posición de reshpae, esta IO esperará a que la remodelación avance; 4) continúe remodelando, luego md_start_sync() encontró que hay un disco de repuesto que se puede agregar a conf, se llama a mddev_suspend(); Los pasos 4 y 3 se esperan el uno al otro y se activa el punto muerto. Observé que este problema se encuentra mediante la revisión del código y aún no se ha informado. Solucione este problema al no suspender la matriz durante una remodelación interrumpida, esto es seguro porque la configuración no se cambiará hasta que finalice la remodelación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No registre sync_thread para remodelar directamente Actualmente, si se interrumpe el proceso de remodelación, volver a ensamblar la matriz registrará sync_thread directamente desde pers->run(), en este caso 'MD_RECOVERY_RUNNING ' se configura directamente, sin embargo, no hay garantía de que md_do_sync() se ejecute, por lo tanto, stop_sync_thread() se bloqueará porque 'MD_RECOVERY_RUNNING' no se puede borrar. En el último parche, asegúrese de que md_do_sync() establezca MD_RECOVERY_DONE; sin embargo, dm-raid test shell/lvconvert-raid-reshape.sh ocasionalmente puede activar el siguiente bloqueo: [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [ dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/ 0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0 >] Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Mientras tanto mddev->recovery es: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Solucione este problema eliminando el código para registrar sync_thread directamente desde raid10 y raid5. Y deje que md_check_recovery() registre sync_thread.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md: No ignorar la matriz de solo lectura en md_check_recovery() Generalmente, si la matriz no es de lectura y escritura, md_check_recovery() no registrará un nuevo sync_thread en primer lugar. Y si la matriz es de lectura y escritura y sync_thread está registrado, md_set_readonly() cancelará el registro de sync_thread antes de configurar la matriz como de solo lectura. md/raid sigue este comportamiento, por lo que no hay problema. Después de commit f52f5c71f3d4 ("md: arreglar la detención del hilo de sincronización"), el siguiente bloqueo puede activarse mediante test shell/integrity-caching.sh: 1) la matriz es de solo lectura. Superbloque de actualización dm-raid: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> establecer matriz de lectura y escritura md_update_sb 2) registrar un nuevo hilo de sincronización simultáneamente. 3) dm-raid vuelve a configurar la matriz en solo lectura: rs_update_sbs mddev->ro = ro 4) detiene la matriz: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) hilo de sincronización realizado: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) el hilo del demonio no puede cancelar el registro del hilo de sincronización: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING no se puede borrar, por lo tanto el paso 4 se bloquea; La causa principal es que dm-raid manipula 'mddev->ro' por sí solo; sin embargo, dm-raid realmente debería detener el hilo de sincronización antes de configurar la matriz como de solo lectura. Desafortunadamente, necesito leer más código antes de poder refactorizar el controlador de 'mddev->ro' en dm-raid, por lo tanto, solucionemos el problema de la manera más fácil por ahora para evitar la regresión de dm-raid.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No ignorar la matriz suspendida en md_check_recovery() mddev_suspend() nunca detiene sync_thread, por lo tanto, no tiene sentido ignorar la matriz suspendida en md_check_recovery(), lo que podría causar sync_thread no se puede cancelar el registro. Después de commit f52f5c71f3d4 ("md: arreglar la detención del hilo de sincronización"), el siguiente bloqueo se puede activar mediante test shell/integrity-caching.sh: 1) suspender la matriz: raid_postsuspend mddev_suspend 2) detener la matriz: raid_dtr md_stop __md_stop_writes stop_sync_thread set_bit(MD_RECOVERY_INTR , &mddev->recuperación); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 3) hilo de sincronización realizado: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 4) el hilo del demonio no puede cancelar el registro del hilo de sincronización: md_check_recovery si (mddev->suspended) regresa; -> devolver directamente md_read_sync_thread clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery); -> MD_RECOVERY_RUNNING no se puede borrar, por lo tanto el paso 2 se bloquea; Este problema no solo está relacionado con dm-raid; solucionelo ignorando la matriz suspendida en md_check_recovery(). Y los parches de seguimiento mejorarán mejor dm-raid para congelar el hilo de sincronización durante la suspensión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/swap: corrige la ejecución al omitir swapcache Al omitir swapcache para SWP_SYNCHRONOUS_IO, si dos o más subprocesos intercambian la misma entrada al mismo tiempo, obtienen páginas diferentes (A, B) . Antes de que un subproceso (T0) finalice el intercambio e instale la página (A) en el PTE, otro subproceso (T1) podría finalizar el intercambio de la página (B), liberar la entrada y luego intercambiar la página posiblemente modificada reutilizando la misma entrada. Rompe el control pte_same (T0) porque el valor de PTE no cambia, lo que provoca un problema de ABA. El subproceso (T0) instalará una página bloqueada (A) en el PTE y provocará daños en los datos. Una posible pila de llamadas es así: CPU0 CPU1 ---- ---- do_swap_page() do_swap_page() con la misma entrada swap_read_folio() < - leer en la página A swap_read_folio() <- leer en la página B ... set_pte_at() swap_free() <- la entrada es libre pte_same() <- Verificar pase, PTE parece no haber cambiado, ¡pero la página A está estancada! swap_free() <- ¡Contenido de la página B perdido! set_pte_at() <- ¡página A obsoleta instalada! Y además, para ZRAM, swap_free() permite que el dispositivo de intercambio descarte el contenido de la entrada, por lo que incluso si la página (B) no se modifica, si swap_read_folio() en CPU0 ocurre más tarde que swap_free() en CPU1, también puede causar que los datos pérdida. Para solucionar este problema, reutilice swapcache_prepare, que fijará la entrada de intercambio usando el indicador de caché y permitirá que solo un hilo la intercambie, y también evitará que cualquier código paralelo coloque la entrada en el caché. Suelte el pasador después de desbloquear el PT. Los corredores simplemente dan vueltas y esperan, ya que es un evento raro y muy corto. Se agrega una llamada Schedule_timeout_uninterruptible(1) para evitar errores repetidos de página que desperdician demasiada CPU, provocando bloqueos en vivo o agregando demasiado ruido a las estadísticas de rendimiento. Un problema similar de livelock se describió en el compromiso 029c4628b2eb ("mm: swap: deshacerse de livelock en swapin readahead") Reproductor: este problema de ejecución se puede activar fácilmente utilizando un reproductor bien construido y un brd parcheado (con un retraso en la ruta de lectura) [ 1]: Con la última línea principal 6.8, la pérdida de datos causada por la ejecución se puede observar fácilmente: $ gcc -g -lpthread test-thread-swap-race.c && ./a.out Contaminando 32 MB de región de memoria... Siga intercambiando. .. Comenzando la ronda 0... Generando 65536 trabajadores... Se generaron 32746 trabajadores, espere a que termine... Ronda 0: Error en 0x5aa00, se esperaban 32746, obtuve 32743, ¡3 pérdida de datos! Ronda 0: Error en 0x395200, se esperaba 32746, obtuve 32743, ¡3 pérdida de datos! Ronda 0: Error en 0x3fd000, esperado 32746, obtuve 32737, ¡9 pérdida de datos! Ronda 0 fallida, ¡15 pérdida de datos! Este reproductor genera múltiples subprocesos que comparten la misma región de memoria mediante un pequeño dispositivo de intercambio. Cada dos subprocesos actualiza las páginas asignadas una por una en dirección opuesta tratando de crear una ejecución, con un subproceso dedicado sigue intercambiando los datos usando madvise. El reproductor creó una tasa de reproducción de aproximadamente una vez cada 5 minutos, por lo que la ejecución debería ser totalmente posible en producción. Después de este parche, ejecuté el reproductor durante más de unos cientos de rondas y no se observó pérdida de datos. ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: target: pscsi: corrige bio_put() para el caso de error A partir del commit 066ff571011d ("bloque: convierte bio_kmalloc en un contenedor kmalloc simple"), una biografía asignada por bio_kmalloc() debe ser liberado por bio_uninit() y kfree(). Esto no se hace correctamente en el caso de error, al presionar WARN y desreferenciar el puntero NULL en bio_free().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/pci: corrige la desactivación de la memoria si el rango DVSEC CXL no coincide con una ventana CFMWS. El subSYSTEM Linux CXL se basa en el supuesto de que HPA == SPA. Es decir, la dirección física del host (HPA) con la que están programados los registros del decodificador HDM son direcciones físicas del SYSTEM (SPA). Durante la configuración del decodificador HDM, los registros de rango DVSEC CXL (cxl-3.1, 8.1.3.8) se verifican si la memoria está habilitada y el rango CXL está en una ventana HPA que se describe en una estructura CFMWS del puente de host CXL (cxl- 3.1, 9.18.1.3). Ahora, si el HPA no es un SPA, el rango CXL no coincide con una ventana CFMWS y el rango de memoria CXL se desactivará en ese momento. El descodificador HDM deja de funcionar, lo que provoca que la memoria del SYSTEM se desactive y, además, el SYSTEM se cuelgue durante la inicialización del descodificador HDM, normalmente cuando se inicia un kernel habilitado para CXL. Evite que el SYSTEM se cuelgue y no desactive el decodificador HDM si el rango CXL del decodificador no se encuentra en una ventana CFMWS. Tenga en cuenta que el cambio solo soluciona un problema de hardware, pero no implementa la traducción HPA/SPA. Se puede agregar soporte para esto en una serie de parches de seguimiento.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/pci: omita para manejar errores RAS si el dispositivo CXL.mem está desconectado. El modelo PCI AER no es adecuado para el manejo de errores CXL. Si bien la expectativa es que un dispositivo PCI pueda escalar hasta restablecer el enlace para recuperarse de un evento AER, el mismo restablecimiento en CXL equivale a una conexión en caliente sorpresa de cantidades masivas de memoria. Actualmente, el controlador de errores CXL intenta un manejo optimista de errores para desvincular el dispositivo del controlador cxl_mem después de obtener algunos valores de registro RAS. Esto da como resultado un intento "esperanzador" de desconectar la memoria, pero no hay garantía de que tenga éxito. Una notificación AER posterior después del evento de desvinculación de memdev ya no puede asumir que los registros están asignados. Verifique el enlace de memdev antes de obtener los valores del registro de estado para evitar fallas del tipo: ERROR: no se puede manejar el error de página para la dirección: ffa00000195e9100 #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - página no presente [. ..] RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core] [...] Seguimiento de llamadas: ? __morir+0x24/0x70 ? page_fault_oops+0x82/0x160? kernelmode_fixup_or_oops+0x84/0x110? exc_page_fault+0x113/0x170? asm_exc_page_fault+0x26/0x30? __pfx_dpc_reset_link+0x10/0x10 ? __cxl_handle_ras+0x30/0x110 [cxl_core] ? find_cxl_port+0x59/0x80 [cxl_core] cxl_handle_rp_ras+0xbc/0xd0 [cxl_core] cxl_error_detected+0x6c/0xf0 [cxl_core] report_error_detected+0xc7/0x1c0 pci_walk_bus+0x73/0x90 pcie_do_recovery+0x23f/0x330 A más largo plazo, es posible que sea necesario corregir el comportamiento de desvinculación y PCI_ERS_RESULT_DISCONNECT. ser reemplazado por un nuevo PCI_ERS_RESULT_PANIC.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: dm-crypt: no modifica los datos cuando se utiliza cifrado autenticado Se dijo que el cifrado autenticado podría producir etiquetas no válidas cuando se modifican los datos que se están cifrando [1]. Entonces, solucione este problema copiando primero los datos en la biografía del clon y luego cifrándolos dentro de la biografía del clon. Esto puede reducir el rendimiento, pero es necesario para evitar que el usuario dañe el dispositivo escribiendo datos con O_DIRECT y modificándolos al mismo tiempo. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/aio: restringe kiocb_set_cancel_fn() a E/S enviadas a través de libaio. Si se llama a kiocb_set_cancel_fn() para E/S enviadas a través de io_uring, aparece la siguiente advertencia del kernel: ADVERTENCIA: CPU : 3 PID: 368 en fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Rastreo de llamadas: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/ 0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Solucionar esto configurando el IOC Bandera B_AIO_RW para E/S de lectura y escritura enviada por libaio .