Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: intenta corregir fallas de segmentación aleatoria en compilaciones de paquetes. Los sistemas PA-RISC con procesadores PA8800 y PA8900 han tenido problemas con fallas de segmentación aleatoria durante muchos años. Los sistemas con procesadores anteriores son mucho más estables. Los sistemas con procesadores PA8800 y PA8900 tienen una gran caché L2 que necesita un vaciado por página para un rendimiento decente cuando se vacía un rango grande. La caché combinada en estos sistemas también es más sensible a alias no equivalentes que las cachés de sistemas anteriores. La mayoría de los fallos de segmentación aleatoria que he observado parecen ser daños en la memoria asignada mediante mmap y malloc. Mi primer intento de solucionar los fallos aleatorios no funcionó. Al revisar el código de caché, me di cuenta de que había dos problemas que el código existente no manejaba correctamente. Ambos se relacionan con la entrada de caché. Otro problema es que la actualidad en las PTE es picante. 1) Los cachés PA-RISC tienen mente propia y pueden cargar especulativamente datos e instrucciones para una página siempre que haya una entrada en el TLB para la página que permita la entrada. Los TLB son locales para cada CPU. Por lo tanto, la entrada TLB de una página debe eliminarse antes de eliminarla. Esto es particularmente importante en los sistemas SMP. En algunas de las rutinas de vaciado, se llamaría a la rutina de vaciado y luego se purgaría la entrada TLB. Esto se debía a que la rutina de lavado necesitaba la entrada TLB para realizar el lavado. 2) Mi enfoque inicial para intentar solucionar las fallas aleatorias fue intentar usar Flush_cache_page_if_present para todas las operaciones de descarga. En realidad, esto empeoró las cosas y provocó un par de bloqueos de hardware. Finalmente me di cuenta de que algunas líneas no se estaban borrando porque el código de verificación del pte era picante. Esto resultó en asignaciones aleatorias no equivalentes a páginas físicas. La descarga tmpalias __flush_cache_page configura su propia entrada TLB y no necesita la entrada TLB existente. Siempre que podamos encontrar el puntero pte de la página vm, podemos obtener el pfn y la dirección física de la página. También podemos purgar la entrada TLB de la página antes de realizar el vaciado. Además, __flush_cache_page utiliza una entrada TLB especial que inhibe la entrada de caché. Al cambiar las asignaciones de páginas, debemos asegurarnos de que las líneas se eliminen del caché. No es suficiente simplemente borrar las líneas de la memoria, ya que pueden volver. Esto dejó en claro que necesitábamos implementar todas las operaciones de vaciado necesarias utilizando rutinas tmpalias. Esto incluye vaciados para páginas de usuario y de kernel. Después de modificar el código para usar tmpalias vaciados, quedó claro que los errores de segmentación aleatoria no se resolvieron por completo. La frecuencia de fallas fue peor en sistemas con 64 MB L2 (PA8900) y sistemas con más CPU (rp4440). La advertencia que agregué a Flush_cache_page_if_present para detectar páginas que no se podían vaciar se activaba con frecuencia en algunos sistemas. Helge y yo miramos las páginas que no se podían vaciar y descubrimos que la PTE estaba vacía o era una página de intercambio. Ignorar las páginas que se intercambiaron parecía estar bien, pero las páginas con PTE borradas parecían problemáticas. Miré rutinas relacionadas con pte_clear y noté ptep_clear_flush. La implementación predeterminada simplemente vacía la entrada TLB. Sin embargo, era obvio que en París también necesitamos vaciar la página de caché. Si no limpiamos la página de caché, quedarán líneas obsoletas en la caché y provocarán daños aleatorios. Una vez que se borra una PTE, no hay forma de encontrar la dirección física asociada con la PTE y borrar la página asociada más adelante. ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: memblock: make memblock_set_node() también advierte sobre el uso de MAX_NUMNODES En un sistema x86 (antiguo) con SRAT que solo cubre espacio superior a 4 Gb: ACPI: SRAT: Nodo 0 PXM 0 [mem 0x100000000 -0xfffffffff] hotplug, El commit a la que se hace referencia a continuación hace que esta configuración NUMA ya no sea rechazada por un kernel CONFIG_NUMA=y (anteriormente NUMA: los nodos solo cubren 6144 MB de su RAM e820 de 8185 MB. No se usa. No se encontró ninguna configuración NUMA Falsificar un nodo en [mem 0x0000000000000000-0x000000027fffffff] se vio en el registro directamente después del mensaje citado anteriormente), debido a que memblock_validate_numa_coverage() verifica NUMA_NO_NODE (solamente). Esto a su vez llevó a la advertencia de memblock_alloc_range_nid() sobre la activación de MAX_NUMNODES, seguida de una deref NULL en memmap_init() al intentar acceder a los datos del nodo 64 (NODE_SHIFT=6). Para compensar dicho cambio, active memblock_set_node() y ajuste un valor pasado de MAX_NUMNODES, tal como lo hacen otras funciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Ajusta el registro de mensajes de firmware en caso de token liberado en __hwrm_send() En caso de que el token se libere debido al token->estado == BNXT_HWRM_DEFERRED, token liberado (establecido en NULL ) se utiliza en mensajes de registro. Se espera que este problema se evite mediante el código de error HWRM_ERR_CODE_PF_UNAVAILABLE. Pero este código de error lo devuelve un firmware reciente. Por lo tanto, es posible que algunos firmware no lo devuelvan. Esto puede provocar una desreferencia del puntero NULL. Ajuste este problema agregando una verificación del puntero del token. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/io-wq: use set_bit() y test_bit() en trabajador->flags Utilice set_bit() y test_bit() en trabajador->flags dentro de io_uring/io-wq para abordar posibles ejecucións de datos. Se puede acceder a la estructura io_worker->flags a través de varias rutas de datos, lo que genera problemas de concurrencia. Cuando KCSAN está habilitado, revela ejecucións de datos que ocurren en las funciones io_worker_handle_work y io_wq_activate_free_worker. ERROR: KCSAN: ejecución de datos en io_worker_handle_work/io_wq_activate_free_worker escribe en 0xffff8885c4246404 de 4 bytes por tarea 49071 en la CPU 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) (io_durante/io -wq.c:?) leer en 0xffff8885c4246404 de 4 bytes por tarea 49024 en la CPU 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io- wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198) Números de línea contra El commit 18daea77cca6 ("Etiqueta de combinación 'para -linus' de git://git.kernel.org/pub/scm/virt/kvm/kvm"). Estas ejecuciones implican escrituras y lecturas en la misma ubicación de memoria mediante diferentes tareas que se ejecutan en diferentes CPU. Para mitigar esto, refactorice el código para usar operaciones atómicas como set_bit(), test_bit() y clear_bit() en lugar de operaciones básicas "y" y "o". Esto garantiza una manipulación segura para subprocesos de los indicadores de los trabajadores. Además, mueva `create_index` para evitar agujeros en la estructura.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: núcleo: eliminar WARN_ON() innecesario en implementar() Syzkaller recibió una advertencia [1] en una llamada a implementar() al intentar escribir un valor en un campo de tamaño más pequeño. tamaño en un informe de salida. Dado que implement() ya tiene un mensaje de advertencia impreso con la ayuda de hid_warn() y el valor en cuestión se recorta con: ... value &= m; ... WARN_ON puede considerarse superfluo. Elimínelo para suprimir futuros desencadenantes de syzkaller. [1] ADVERTENCIA: CPU: 0 PID: 5084 en drivers/hid/hid-core.c:1451 implementar drivers/hid/hid-core.c:1451 [en línea] ADVERTENCIA: CPU: 0 PID: 5084 en drivers/hid /hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 Módulos vinculados en: CPU: 0 PID: 5084 Comm: syz-executor424 No contaminado 6.9.0-rc7-syzkaller-00183 -gcf87f46fd34d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [en línea] RIP: 0010:hid_output_report+0x548/ 0x760 drivers/hid/hid-core.c:1863... Seguimiento de llamadas: __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [en línea] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid -core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0xfc/0x170 fs /ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f...

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cachefiles: fix slab-use-after-free in cachefiles_ondemand_daemon_read() Obtuvimos el siguiente problema en una prueba de ejecución aleatoria del comando de restauración: ======== ==================================================== ======== ERROR: KASAN: slab-use-after-free en cachefiles_ondemand_daemon_read+0xb41/0xb60 Lectura de tamaño 8 en la dirección ffff888122e84088 por tarea ondemand-04-dae/963 CPU: 13 PID: 963 Comm: ondemand -04-dae Not tainted 6.8.0-dirty #564 Seguimiento de llamadas: kasan_report+0x93/0xc0 cachefiles_ondemand_daemon_read+0xb41/0xb60 vfs_read+0x169/0xb50 ksys_read+0xf5/0x1e0 Asignado por tarea 116: kmem_cache_alloc+0x14 0/0x3a0 cachefiles_lookup_cookie+0x140/ 0xcd0 fscache_cookie_state_machine+0x43c/0x1230 [...] Liberado por la tarea 792: kmem_cache_free+0xfe/0x390 cachefiles_put_object+0x241/0x480 fscache_cookie_state_machine+0x5c8/0x1230 [...] =============== ==================================================== == El siguiente es el proceso que desencadena el problema: montar | daemon_thread1 | daemon_thread2 ------------------------------------------------- ----------- cachefiles_withdraw_cookie cachefiles_ondemand_clean_object(object) cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done) cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req- >object_id = solicitud->objeto ->ondemand->ondemand_id ------ restaurar ------ cachefiles_ondemand_restore xas_for_each(&xas, req, ULONG_MAX) xas_set_mark(&xas, CACHEFILES_REQ_NEW) cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req er, mensaje, n) xa_erase(&cache ->reqs, id) complete(&REQ_A->done) ------ close(fd) ------ cachefiles_ondemand_fd_release cachefiles_put_object cachefiles_put_object kmem_cache_free(cachefiles_object_jar, object) REQ_A->object->ondemand->ondemand_id // objeto UAF !!! Cuando vemos la solicitud dentro de xa_lock, req->object no debe haberse liberado aún, así que tome el recuento de referencia del objeto antes de xa_unlock para evitar el problema anterior.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cachefiles: fix slab-use-after-free in cachefiles_ondemand_get_fd() Obtuvimos el siguiente problema en una prueba de ejecución aleatoria del comando de restauración: ======== ==================================================== ======== ERROR: KASAN: slab-use-after-free en cachefiles_ondemand_daemon_read+0x609/0xab0 Escritura de tamaño 4 en la dirección ffff888109164a80 por tarea ondemand-04-dae/4962 CPU: 11 PID: 4962 Comm: ondemand -04-dae No contaminado 6.8.0-rc7-dirty #542 Seguimiento de llamadas: kasan_report+0x94/0xc0 cachefiles_ondemand_daemon_read+0x609/0xab0 vfs_read+0x169/0xb50 ksys_read+0xf5/0x1e0 Asignado por tarea 626: /0x4b0 archivos de caché_ondemand_send_req+ 0x24d/0x690 cachefiles_create_tmpfile+0x249/0xb30 cachefiles_create_file+0x6f/0x140 cachefiles_look_up_object+0x29c/0xa60 cachefiles_lookup_cookie+0x37d/0xca0 fscache_cookie_state_machine+0x43c/0x1230 [...] Liberado por tarea 626: kfree+0xf1/0x2c0 cachefiles_ondemand_send_req+0x568/0x690 cachefiles_create_tmpfile+ 0x249/0xb30 cachefiles_create_file+0x6f/0x140 cachefiles_look_up_object+0x29c/0xa60 cachefiles_lookup_cookie+0x37d/0xca0 fscache_cookie_state_machine+0x43c/0x1230 [...] ======================= ============================================= El siguiente es el proceso que desencadena el problema: montar | daemon_thread1 | daemon_thread2 ------------------------------------------------- ----------- cachefiles_ondemand_init_object cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done) cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req cachefiles_ondemand_get_fd usuario(_buffer, msg, n) proceso_open_req(REQ_A) ------ restaurar ------ cachefiles_ondemand_restore xas_for_each(&xas, req, ULONG_MAX) xas_set_mark(&xas, CACHEFILES_REQ_NEW); cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req write(devfd, ("copen %u,%llu", msg->msg_id, tamaño)); cachefiles_ondemand_copen xa_erase(&cache->reqs, id) complete(&REQ_A->done) kfree(REQ_A) cachefiles_ondemand_get_fd(REQ_A) fd = get_unused_fd_flags file = anon_inode_getfile fd_install(fd, file) load = (void *)REQ_A->msg.data; cargar->fd = fd; // carga UAF !!! Este problema se debe a la emisión de un comando de restauración cuando el daemon todavía está activo, lo que da como resultado que una solicitud se procese varias veces y, por lo tanto, se active una UAF. Entonces, para evitar este problema, agregue un recuento de referencia adicional a cachefiles_req, que se mantiene mientras se espera y se lee, y luego se libera cuando finaliza la espera y la lectura. Tenga en cuenta que, dado que solo hay un recuento de referencias para esperar, debemos evitar que la misma solicitud se complete varias veces, por lo que solo podemos completar la solicitud si se elimina con éxito del xarray.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: elimina solicitudes de xarray durante las solicitudes de vaciado Incluso con CACHEFILES_DEAD configurado, aún podemos leer las solicitudes, por lo que en la siguiente concurrencia la solicitud se puede usar después de que se haya liberado: mount | daemon_thread1 | daemon_thread2 ------------------------------------------------- --------- Cachefiles_ondemand_init_object Cachefiles_ondemand_send_req req_a = kzalloc (sizeof (*req) + data_len) Wait_for_completion (& req_a-> ded) gratis (req_a ) xa_lock(&cache->reqs); cachefiles_ondemand_select_req req->msg.opcode != CACHEFILES_OP_READ // ¡¡¡requiere use-after-free !!! xa_unlock(&cache->reqs); xa_destroy(&cache->reqs) Por lo tanto, elimine las solicitudes de cache->reqs cuando las vacíe para evitar acceder a las solicitudes liberadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Evite que test/set_bit() opere en memoria no asignada. Existe un posible acceso fuera de los límites cuando se usa test_bit() en una sola palabra. Las funciones test_bit() y set_bit() operan con valores largos y, al probar o configurar una sola palabra, pueden exceder el límite de la palabra. KASAN detecta este problema y produce un volcado: ERROR: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/ bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Escritura de tamaño 8 en la dirección ffff8881d26e3c60 mediante tarea kworker/u1536:2/2965 Para obtener el registro completo, consulte [1]. Realice la asignación al menos del tamaño de sizeof(unsigned long) para que set_bit() y test_bit() tengan suficiente espacio para operaciones de lectura/escritura sin sobrescribir la memoria no asignada. [1] Enlace: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jfs: xattr: corrige el desbordamiento del búfer para xattr no válido Cuando un tamaño de xattr no es el esperado, se imprime en el registro del kernel en formato hexadecimal como una forma de depuración. Pero cuando el tamaño de xattr es mayor que el tamaño esperado, imprimirlo puede provocar un acceso desde el final del búfer. Solucione todo esto restringiendo adecuadamente el tamaño del volcado hexadecimal de depuración en el registro del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: arreglar el caso de use-after-free en tcpm_register_source_caps Podría haber un posible caso de use-after-free en tcpm_register_source_caps(). Esto podría suceder cuando: * se anuncian límites de fuente nuevos (por ejemplo, no válidos) * los límites de fuente existentes no están registrados * tcpm_register_source_caps() devuelve un error ya que usb_power_delivery_register_capabilities() falla Esto hace que port->partner_source_caps conserve los límites de fuente ahora liberados. Restablezca el valor de puerto->partner_source_caps a NULL después de cancelar el registro de los límites de origen existentes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: USB: clase: cdc-wdm: soluciona el bloqueo de la CPU causado por mensajes de registro excesivos. El syzbot fuzzer descubrió que la devolución de llamada de finalización de interrupción-URB en el controlador cdc-wdm estaba tardando demasiado y el reenvío inmediato por parte del controlador de las URB de interrupción con estado -EPROTO combinado con la emulación ficticia-hcd para provocar un bloqueo de la CPU: cdc_wdm 1-1:1.0: estado de urb distinto de cero recibido: -71 cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes perro guardián: ERROR: bloqueo suave - ¡CPU#0 bloqueada durante 26 segundos! [syz-executor782:6625] CPU#0 Utilización cada 4 segundos durante el bloqueo: #1: 98% sistema, 0% softirq, 3% hardirq, 0% inactivo #2: 98% sistema, 0% softirq, 3% hardirq, 0 % inactivo #3: 98% sistema, 0% softirq, 3% hardirq, 0% inactivo #4: 98% sistema, 0% softirq, 3% hardirq, 0% inactivo #5: 98% sistema, 1% softirq, 3 % hardirq, 0% inactivo Módulos vinculados en: irq event stamp: 73096 hardirqs habilitado por última vez en (73095): [] console_emit_next_record kernel/printk/printk.c:2935 [inline] hardirqs habilitado por última vez en (73095): [ ] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs deshabilitado por última vez en (73096): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [en línea] hardirqs último deshabilitado en (73096): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs habilitado por última vez en (73048): [] softirq_handle_end kernel/softirq.c:400 [en línea] softirqs habilitados por última vez en (73048): [] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs deshabilitados por última vez en (73043): [] __do_softirq+0x14/0x20 kernel/softirq. c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Contaminado: GW 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 Las pruebas mostraron que el problema no se produjo si se eliminaron los dos mensajes de error (las dos primeras líneas anteriores); aparentemente agregar material al registro del kernel lleva una cantidad de tiempo sorprendentemente grande. En cualquier caso, el mejor enfoque para prevenir estos bloqueos y evitar enviar spam al registro con miles de mensajes de error por segundo es limitar la velocidad de las dos llamadas dev_err(). Por eso los reemplazamos con dev_err_ratelimited().