Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: ttpci: corrige dos fugas de mem en Budget_av_attach Cuando fallan saa7146_register_device y saa7146_vv_init, Budget_av_attach debería liberar los recursos que asigna, como lo hace el manejo de errores de ttpci_budget_init. Además, hay dos comentarios fijos que se refieren a dichas desasignaciones.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: go7007: corrige una fuga de memoria en go7007_load_encoder En go7007_load_encoder, el rebote (es decir, go->boot_fw) se asigna sin una desasignación posterior. Después de la siguiente cadena de llamadas: saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go) go se libera y, por lo tanto, se filtra el rebote.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: imx: csc/scaler: corrige la pérdida de memoria v4l2_ctrl_handler Libere la memoria asignada en v4l2_ctrl_handler_init en el lanzamiento.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: v4l2-mem2mem: corrige una fuga de mem en v4l2_m2m_register_entity La entidad->nombre (es decir, nombre) se asigna en v4l2_m2m_register_entity pero no se libera en las siguientes rutas de manejo de errores. Este parche agrega dicha desasignación para evitar la fuga de memoria de entidad->nombre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medio: v4l2-tpg: corrige algunas fugas de memoria en tpg_alloc En tpg_alloc, los recursos deben desasignarse en todas y cada una de las rutas de manejo de errores, ya que se asignan en declaraciones for. De lo contrario, habría memleaks porque se llama a tpg_free solo cuando tpg_alloc devuelve 0.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/vt-d: corrige el dominio NULL al lanzar el dispositivo. En el kernel kdump, IOMMU opera en modo deferred_attach. En este modo, es posible que info->dominio aún no esté asignado cuando se llama a la función release_device. Conduce al siguiente bloqueo en el kernel bloqueado: ERROR: desreferencia del puntero NULL del kernel, dirección: 000000000000003c ... RIP: 0010:do_raw_spin_lock+0xa/0xa0 ... _raw_spin_lock_irqsave+0x1b/0x30 intel_iommu_release_device+0x96/0x170 +0x39/ 0xf0 __iommu_group_remove_device+0xa0/0xd0 iommu_bus_notifier+0x55/0xb0 notifier_call_chain+0x5a/0xd0 blocking_notifier_call_chain+0x41/0x60 bus_notify+0x34/0x50 device_del+0x269/0x3d0 vice+0x77/0x100 p2sb_bar+0xae/0x1d0 ... i801_probe+0x423/0x740 Uso el mecanismo release_domain para solucionarlo. La entrada de contexto del modo escalable que no forma parte del dominio de lanzamiento debe borrarse en release_device().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige la ejecución al detectar rangos de delalloc durante fiemap Para fiemap recientemente dejamos de bloquear el rango de extensión objetivo durante toda la duración de la llamada a fiemap, para evitar un punto muerto en un escenario donde el búfer fiemap resulta ser un rango mapeado en memoria del mismo archivo. Es muy poco probable que este caso de uso sea útil en la práctica, pero puede activarse mediante pruebas difusas (syzbot, etc.). Sin embargo, esto introdujo una ejecución que nos hace perder rangos de delalloc para regiones de archivos que actualmente están vacías, por lo que quien llama a fiemap no sabrá que hay datos para algunas regiones de archivos. Esto puede ser bastante grave en algunos casos de uso; por ejemplo, en las versiones de Coreutils anteriores a la 9.0, el programa cp utilizaba fiemap para detectar agujeros y datos en el archivo de origen, copiando solo regiones con datos (extensiones o delalloc) del archivo de origen al destino. archivo para preservar los agujeros (consulte la documentación para conocer su opción de línea de comando --sparse). Esto significa que si se usó cp con un archivo de origen que tenía delalloc en un agujero, el archivo de destino podría terminar sin esos datos, lo que efectivamente es un problema de pérdida de datos, si llegara a la ejecución que se describe a continuación. La ejecución ocurre así: 1) Se llama a Fiemap, sin el indicador FIEMAP_FLAG_SYNC, para un archivo que tiene delalloc en el rango de archivos [64M, 65M[, que actualmente es un agujero; 2) Fiemap bloquea el inodo en modo compartido, luego comienza a iterar el árbol de subvolumen del inodo buscando elementos de extensión de archivo, sin tener todo el rango objetivo de fiemap bloqueado en el árbol io del inodo - el cambio introducido recientemente por el commit b0ad381fa769 ("btrfs: fix deadlock" con fiemap y bloqueo de extensión"). Solo bloquea rangos en el árbol io cuando encuentra un agujero o una extensión de asignación previa desde esa confirmación; 3) Tenga en cuenta que fiemap clona cada hoja antes de usarla, y esto es para evitar interbloqueos al bloquear un rango de archivos en el árbol io del inodo y el búfer de fiemap está asignado en memoria a algún archivo, porque escribir en la página con btrfs_page_mkwrite() esperará en cualquier extensión ordenada para el rango de la página y la extensión ordenada necesita bloquear el rango y puede necesitar modificar la misma hoja, lo que lleva a un punto muerto en la hoja; 4) Mientras se iteran los elementos de extensión del archivo en la hoja clonada antes de encontrar el hueco en el rango [64M, 65M[, la delalloc en ese rango se vacía y su extensión ordenada se completa, lo que significa que el elemento de extensión del archivo correspondiente está en el árbol de subvolumen del inodo. , pero no está presente en la hoja clonada sobre la que fiemap está iterando; 5) Cuando fiemap encuentra el agujero en el rango [64M, 65M[ al ver el espacio en la hoja clonada (o un elemento de extensión de archivo con disk_bytenr == 0 en caso de que la función NO_HOLES no esté habilitada), bloqueará ese rango de archivos. en el árbol io del inodo y luego busque delalloc verificando el bit EXTENT_DELALLOC en el árbol io para ese rango y extensiones ordenadas (con btrfs_find_delalloc_in_range()). Pero no encuentra nada ya que la delalloc en ese rango ya se vació y la extensión ordenada se completó y desapareció; como resultado, fiemap no informará que hay delalloc o una extensión para el rango [64M, 65M[, por lo que el espacio del usuario será engañoso a pensar que hay un agujero en ese rango. En realidad, esto podría activarse esporádicamente con el caso de prueba generic/094 de fstests, que informa que falta un rango de extensión/delalloc como este: generic/094 2s ... - falta de coincidencia de salida (consulte /home/fdmanana/git/hub/xfstests/results //generic/094.out.bad) ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: corrige algunas fugas de mem en gssx_dec_option_array Los creds y oa->data deben liberarse en las rutas de manejo de errores después de su asignación. Entonces este parche agrega estas desasignaciones en las rutas correspondientes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pstore: inode: solo se necesita d_invalidate(). La descarga de un backend modular de pstore con registros en pstorefs activaría la advertencia de doble caída de dput(): ADVERTENCIA: CPU: 0 PID: 2569 en fs/dcache.c:762 dput.part.0+0x3f3/0x410 Usar la combinación de d_drop()/dput() (como se menciona en Documentation/filesystems/vfs.rst) no es el enfoque correcto aquí, y conduce al problema de recuento de referencias visto anteriormente. Utilice d_invalidate() y actualice el código para no molestarse en buscar códigos de error que nunca sucederán. ---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: mcast: elimina una barrera de sincronización_net() en ipv6_mc_down() Como se discutió en el pasado (commit 2d3916f31891 ("ipv6: corrige caídas de skb en igmp6_event_query() e igmp6_event_report()" )) Creo que la llamada sincronizar_net() en ipv6_mc_down() no es necesaria. Bajo carga, sincronizar_net() puede durar entre 200 usos y 5 ms. KASAN parece estar de acuerdo también.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: wilc1000: no reasignar la cola de trabajo cada vez que se agrega una interfaz. Commit 09ed8bfc5215 ("wilc1000: cambiar el nombre de la cola de trabajo de "WILC_wq" a "NETDEV-wq"") movió la creación de la cola de trabajo en wilc_netdev_ifc_init para configurar el nombre de la interfaz en el nombre de la cola de trabajo. Sin embargo, aunque el controlador solo necesita una cola de trabajo, se llama a wilc_netdev_ifc_init cada vez que agregamos una interfaz a través de un phy, lo que a su vez sobrescribe la cola de trabajo con una nueva. Esto se puede observar con los siguientes comandos: for i in $(seq 0 10) do iw phy phy0 interfaz add wlan1 tipo administrado iw dev wlan1 del done ps -eo pid,comm|grep wlan 39 kworker/R-wlan0 98 kworker/ R-wlan1 102 ktrabajador/R-wlan1 105 ktrabajador/R-wlan1 108 ktrabajador/R-wlan1 111 ktrabajador/R-wlan1 114 ktrabajador/R-wlan1 117 ktrabajador/R-wlan1 120 ktrabajador/R-wlan1 123 ktrabajador/R- wlan1 126 kworker/R-wlan1 129 kworker/R-wlan1 Solucione esta fuga volviendo a colocar la asignación hif_workqueue en wilc_cfg80211_init. Con respecto al nombre de la cola de trabajo, es relevante establecerlo en minúsculas; sin embargo, no está adjunto a un netdev específico, por lo que hacer cumplir el nombre de netdev en el nombre no es tan relevante. Aún así, enriquezca el nombre con el nombre de wiphy para dejar claro qué phy está usando la cola de trabajo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvme: host: corrige la doble liberación de la estructura nvme_id_ns en ns_update_nuse() Cuando nvme_identify_ns() falla, libera el puntero a la estructura nvme_id_ns antes de que regrese. Sin embargo, ns_update_nuse() llama a kfree() para el puntero incluso cuando nvme_identify_ns() falla. Esto da como resultado KASAN double-free, que se observó con blktests nvme/045 con parches propuestos [1] en el kernel v6.8-rc7. Corrija el doble libre omitiendo kfree() cuando falla nvme_identify_ns().