Vulnerabilidades

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 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: nfs: corrige UAF en escrituras directas En producción hemos estado recibiendo la siguiente advertencia constantemente ------------[ cortar aquí ]----- ------- refcount_t: desbordamiento insuficiente; use-after-free. ADVERTENCIA: CPU: 17 PID: 1800359 en lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Cola de trabajo: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Llamada Seguimiento: ? __advertir+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0? report_bug+0xcc/0x150? handle_bug+0x3d/0x70? exc_invalid_op+0x16/0x40? asm_exc_invalid_op+0x16/0x20? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] Process_one_work+0x12f/0x4a0 trabajador_thread+0x14e/0x3b0? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30 Esto se debe a que estamos completando nfs_direct_request dos veces seguidas. La fuente de esto es cuando tenemos que enviar nuestras solicitudes de confirmación, las procesamos y las enviamos, y luego en la ruta de finalización para las solicitudes de confirmación tenemos if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq); Sin embargo, dado que enviamos solicitudes asincrónicas, a veces tenemos una que se completa antes de enviar la siguiente, por lo que terminamos llamando a complete en nfs_direct_request dos veces. El único otro lugar donde usamos nfs_generic_commit_list() es en __nfs_commit_inode, que envuelve esta llamada en nfs_commit_begin(); nfs_commit_end(); Este es un patrón común para este estilo de manejo de finalización, uno que también se repite en el código directo con llamadas get_dreq()/put_dreq() en el lugar donde procesamos eventos, así como en las rutas de finalización. Solucione este problema utilizando el mismo patrón para las solicitudes de confirmación. Antes, con mi estrés de rocksdb de 200 nodos ejecutándose, esta advertencia aparecía cada 10 minutos. Con mi parche, la prueba de esfuerzo ha estado funcionando durante varias horas sin aparecer.

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 ha resuelto la siguiente vulnerabilidad: mm: swap: corrige la ejecución entre free_swap_and_cache() y swapoff() Anteriormente existía una ventana teórica donde swapoff() podía ejecutar y desmantelar un swap_info_struct mientras se realizaba una llamada a free_swap_and_cache(). corriendo en otro hilo. Esto podría causar, entre otras malas posibilidades, que swap_page_trans_huge_swapped() (llamado por free_swap_and_cache()) acceda a la memoria liberada para swap_map. Este es un problema teórico y no he podido provocarlo a partir de un caso de prueba. Pero ha habido un acuerdo basado en la revisión del código de que esto es posible (ver enlace a continuación). Solucionarlo usando get_swap_device()/put_swap_device(), lo que detendrá swapoff(). Hubo una verificación adicional en _swap_info_get() para confirmar que la entrada de intercambio no era gratuita. Esto no está presente en get_swap_device() porque en general no tiene sentido debido a la ejecución entre obtener la referencia y el intercambio. Así que agregué una verificación equivalente directamente en free_swap_and_cache(). Detalles de cómo provocar un posible problema (gracias a David Hildenbrand por derivar esto): --8<----- __swap_entry_free() podría ser el último usuario y dar como resultado "count == SWAP_HAS_CACHE". swapoff->try_to_unuse() se detendrá tan pronto como si->inuse_pages==0. Entonces la pregunta es: ¿alguien podría reclamar la publicación y activar si->inuse_pages==0, antes de que completemos swap_page_trans_huge_swapped()? Imagine lo siguiente: folio de 2 MiB en el swapcache. Sólo 2 subpáginas siguen siendo referencias mediante entradas de intercambio. El proceso 1 todavía hace referencia a la subpágina 0 mediante la entrada de intercambio. El proceso 2 todavía hace referencia a la subpágina 1 mediante la entrada de intercambio. El proceso 1 se cierra. Llama a free_swap_and_cache(). -> count == SWAP_HAS_CACHE [luego, adelantado en el hipervisor, etc.] El proceso 2 se cierra. Llama a free_swap_and_cache(). -> count == SWAP_HAS_CACHE El proceso 2 continúa, pasa swap_page_trans_huge_swapped() y llama a __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); ¿Qué impide que el intercambio tenga éxito después de que el proceso 2 recuperó el caché de intercambio pero antes de que el proceso 1 terminara su llamada a swap_page_trans_huge_swapped()? --8<-----

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac802154: corrige la liberación de recursos de clave llsec en mac802154_llsec_key_del mac802154_llsec_key_del() puede liberar recursos de una clave directamente sin seguir las reglas de RCU para esperar antes del final de un período de gracia. Esto puede llevar a un use-after-free en caso de que llsec_lookup_key() esté recorriendo la lista de claves en paralelo con una eliminación de clave: refcount_t: suma en 0; use-after-free. ADVERTENCIA: CPU: 4 PID: 16000 en lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Módulos vinculados en: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Nombre de hardware: PC estándar QEMU ( i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Seguimiento de llamadas: llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_ cifrar+ 0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __ sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Además, Las estructuras ieee802154_llsec_key_entry no son liberadas por mac802154_llsec_key_del(): objeto sin referencia 0xffff8880613b6980 (tamaño 64): comm "iwpan", pid 2176, jiffies 4294761134 (edad 60,475 s) volcado hexadecimal (primeros 32 bytes): 8 0d 8f 18 80 88 y siguientes y siguientes 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ........... ..... retroceso: [] __kmem_cache_alloc_node+0x1e2/0x2d0 [] kmalloc_trace+0x25/0xc0 [] mac802154_llsec_key_add+0xac9/0xcf0 ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [] nl802154_add_llsec_key+0x426/0x5b0 [] genl_family_rcv_msg_doit+0x1fe/0x2f0 [] genl_rcv_msg+0x531/0x7d0 [] netlink_rcv_skb+0x169/0x440 [] genl_rcv+0x28/0x40 [] netlink_unicast+0x53c/0x820 [] netlink_sendmsg+0x93b/0xe60 [] ____sys_sendmsg+0xac5/0xca0 [] ___sys_sendmsg+0x11d/0 x1c0 [] __sys_sendmsg+0xfa/0x1d0 [] do_syscall_64+0x45/0xf0 [] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Maneja la liberación adecuada de recursos en la función de devolución de llamada de RCU mac802154_llsec_key_del_rcu(). Tenga en cuenta que si llsec_lookup_key() encuentra una clave, obtiene un recuento a través de llsec_key_get() y copia localmente la identificación de la clave de key_entry (que es un elemento de la lista). Por lo tanto, es seguro llamar a llsec_key_put() y liberar la entrada de la lista después de que transcurra el período de gracia de RCU. Encontrado por el Centro de verificación de Linux (linuxtesting.org).

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3-am62: corrige el comportamiento de descarga/recarga del módulo. Como el PM en tiempo de ejecución está habilitado, el tiempo de ejecución del módulo se puede suspender cuando se llama a .remove(). Realice pm_runtime_get_sync() para asegurarse de que el módulo esté activo antes de realizar cualquier operación de registro. Hacer pm_runtime_put_sync() debería deshabilitar refclk, por lo que no es necesario deshabilitarlo nuevamente. Corrige la siguiente advertencia al eliminar el módulo. [39.705310] ------------[ cortar aquí ]------------ [ 39.710004] clk:162:3 ya deshabilitado [ 39.713941] ADVERTENCIA: CPU: 0 PID : 921 en drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8 Llamamos a of_platform_populate() en .probe(), así que llame a la función de limpieza of_platform_depopulate() en .remove(). Deshágase del ahora innecesario dwc3_ti_remove_core(). Sin esto, la recarga del módulo no funciona correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: agregar manejo de errores en xhci_map_urb_for_dma Actualmente, xhci_map_urb_for_dma() crea un búfer temporal y copia la lista SG en el nuevo búfer lineal. Pero si kzalloc_node() falla, entonces el siguiente sg_pcopy_to_buffer() puede provocar un fallo ya que intenta memcpy al puntero NULL. Entonces devuelve -ENOMEM si kzalloc devuelve un puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: mmcc-apq8084: 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: mmcc-msm8974: 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.