Vulnerabilidades

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 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 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 ha resuelto la siguiente vulnerabilidad: clk: qcom: gcc-ipq6018: 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: ubifs: ubifs_symlink: corrige la fuga de memleak de inodo->i_link en la ruta de error Para el manejo de errores en la ruta en ubifs_symlink(), el inodo se marcará como incorrecto primero y luego se invocará iput(). Si inode->i_link se inicializa mediante fscrypt_encrypt_symlink() en el escenario de cifrado, inode->i_link no será liberado por la cadena de llamadas ubifs_free_inode -> fscrypt_free_inode en la ruta de manejo de errores, porque make_bad_inode() ha cambiado 'inode->i_mode' como 'S_IFREG '. El siguiente kmemleak es fácil de reproducir inyectando un error en ubifs_jnl_update() al realizar un enlace simbólico en un escenario de cifrado: objeto sin referencia 0xffff888103da3d98 (tamaño 8): comm "ln", pid 1692, jiffies 4294914701 (edad 12.045 s) backtrace: kmemdup+0x32/ 0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 Hay dos formas de solucionarlo: 1. Eliminar make_bad _inode() en la ruta de manejo de errores. Podemos hacer eso porque ubifs_evict_inode() realizará los mismos procesos para el inodo de enlace simbólico bueno y el inodo de enlace simbólico incorrecto, para inodo->i_nlink la verificación es antes de is_bad_inode(). 2. Libere inodo->i_link antes de marcar el inodo como incorrecto. Se elige el método 2, creo que tiene menos influencia, personalmente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fat: corrige el campo no inicializado en los identificadores de archivos notale Cuando fat_encode_fh_nostale() codifica el identificador de archivo sin un padre, almacena solo los primeros 10 bytes del identificador de archivo. Sin embargo, la longitud del identificador del archivo debe ser múltiplo de 4, por lo que el identificador del archivo tiene en realidad 12 bytes de longitud y los dos últimos bytes permanecen sin inicializar. Esto no es bueno porque potencialmente filtramos información no inicializada con el identificador al espacio de usuario. Inicialice correctamente toda la longitud del mango.

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: gcc-ipq5018: 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().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: btnxpuart: Reparar btnxpuart_close Reparar la programación mientras el ERROR atómico en btnxpuart_close(), purgar adecuadamente la cola de transmisión y liberar el skb de recepción. [10.973809] ERROR: programación mientras es atómico: kworker/u9:0/80/0x00000002... [10.980740] CPU: 3 PID: 80 Comm: kworker/u9:0 No contaminado 6.8.0-rc7-0.0.0-devel -00005-g61fdfceacf09 #1 [10.980751] Nombre de hardware: Toradex Verdin AM62 WB en Dahlia Board (DT) [10.980760] Cola de trabajo: hci0 hci_power_off [bluetooth] [10.981169] Seguimiento de llamadas: ... [10.981363] 8/0x78 [ 10.981373] uart_dtr_rts+0x104/0x114 [ 10.981381] tty_port_shutdown+0xd4/0xdc [ 10.981396] tty_port_close+0x40/0xbc [ 10.981407] uart_close+0x34/0x9c [ 10.9814 14] ttyport_close+0x50/0x94 [ 10.981430] serdev_device_close+0x40/0x50 [ 10.981442] btnxpuart_close+0x24/0x98 [btnxpuart] [ 10.981469] hci_dev_close_sync+0x2d8/0x718 [bluetooth] [ 10.981728] hci_dev_do_close+0x2c/0x70 [bluetooth] [ 10.981862] x64 [bluetooth]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm-raid456, md/raid456: soluciona un punto muerto para dm-raid456 mientras io concurre con reshape. Para raid456, si el reshape todavía está en progreso, entonces IO en la posición de reshape esperará remodelar para progresar. Sin embargo, para dm-raid, en los siguientes casos la remodelación nunca progresará, por lo que IO se bloqueará: 1) la matriz es de solo lectura; 2) MD_RECOVERY_WAIT está configurado; 3) MD_RECOVERY_FROZEN está configurado; Después de confirmar c467e97f079f ("md/raid6: use valores de sector válidos para determinar si una E/S debe esperar a la remodelación") solucione el problema de que IO en la posición de remodelación no espera a la remodelación, la prueba dm-raid shell/lvconvert -raid-reshape.sh comienza a colgarse: [root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0 >] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [ <0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [ <0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [ <0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [ <0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Esto se debe a que la remodelación no puede progresar. Para md/raid, el problema no existe porque registrar un nuevo sync_thread ya no depende de que se realice la IO: 1) Si la matriz es de solo lectura, puede cambiar a lectura-escritura mediante ioctl/sysfs; 2) md/raid nunca configuró MD_RECOVERY_WAIT; 3) Si se configura MD_RECOVERY_FROZEN, mddev_suspend() no contiene 'reconfig_mutex', por lo tanto, se puede borrar y la remodelación puede continuar mediante sysfs api 'sync_action'. Sin embargo, todavía no estoy seguro de cómo evitar el problema en dm-raid. Este parche, por un lado, garantiza que raid_message() no pueda cambiar sync_thread() a través de raid_message() después de presuspend(), por otro lado detecta los 3 casos anteriores antes de esperar a que IO se realice en dm_suspend(), y deja dm-raid pone en cola esas IO.