Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> flow_dissector: no diseccionar tramas PPPoE PFC<br /> <br /> La Sección 7 del RFC 2516 establece que la Compresión de Campo de Protocolo (PFC) NO ES RECOMENDADA para PPPoE. En la práctica, pppd no soporta la negociación de PFC para sesiones PPPoE, y el controlador del disector de flujo ha asumido una trama sin comprimir hasta el commit en cuestión.<br /> <br /> Durante el proceso de revisión de ese commit [1], se sugiere el soporte para PFC. Sin embargo, tener un campo de protocolo comprimido (de 1 byte) significa que la carga útil PPP subsiguiente se desplaza un byte, causando una desalineación de 4 bytes para el encabezado de red y una excepción de acceso no alineado en algunas arquitecturas.<br /> <br /> La excepción puede reproducirse enviando una trama PPPoE PFC a una interfaz ethernet de una placa MIPS, con RPS habilitado, incluso si no hay ninguna sesión PPPoE activa en esa interfaz:<br /> <br /> $ 0 : 00000000 80c40000 00000000 85144817<br /> $ 4 : 00000008 00000100 80a75758 81dc9bb8<br /> $ 8 : 00000010 8087ae2c 0000003d 00000000<br /> $12 : 000000e0 00000039 00000000 00000000<br /> $16 : 85043240 80a75758 81dc9bb8 00006488<br /> $20 : 0000002f 00000007 85144810 80a70000<br /> $24 : 81d1bda0 00000000<br /> $28 : 81dc8000 81dc9aa8 00000000 805ead08<br /> Hi : 00009d51<br /> Lo : 2163358a<br /> epc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50<br /> ra : 805ead08 __skb_get_hash_net+0x74/0x12c<br /> Status: 11000403 KERNEL EXL IE<br /> Cause : 40800010 (ExcCode 04)<br /> BadVA : 85144817<br /> PrId : 0001992f (MIPS 1004Kc)<br /> Traza de Llamada:<br /> [] __skb_flow_dissect+0x1b0/0x1b50<br /> [] __skb_get_hash_net+0x74/0x12c<br /> [] get_rps_cpu+0x1b8/0x3fc<br /> [] netif_receive_skb_list_internal+0x324/0x364<br /> [] napi_complete_done+0x68/0x2a4<br /> [] mtk_napi_rx+0x228/0xfec<br /> [] __napi_poll+0x3c/0x1c4<br /> [] napi_threaded_poll_loop+0x234/0x29c<br /> [] napi_threaded_poll+0x8c/0xb0<br /> [] kthread+0x104/0x12c<br /> [] ret_from_kernel_thread+0x14/0x1c<br /> <br /> Código: 02d51821 1060045b 00000000 3084000f 2c820005 144001a2 00042080 8e220000<br /> <br /> Para reducir la superficie de ataque y mantener el rendimiento, no procesar las tramas PPPoE PFC.<br /> <br /> [1] https://lore.kernel.org/r/20220630231016.GA392@debian.home

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: ath5k: no acceder al array OOB<br /> <br /> Vincent informa:<br /> &gt; El controlador ath5k parece realizar un acceso de índice de array fuera de límites como<br /> &gt; mostrado por el mensaje del kernel de UBSAN:<br /> &gt; UBSAN: índice de array fuera de límites en drivers/net/wireless/ath/ath5k/base.c:1741:20<br /> &gt; el índice 4 está fuera de rango para el tipo &amp;#39;ieee80211_tx_rate [4]&amp;#39;<br /> &gt; ...<br /> &gt; Traza de Llamada:<br /> &gt; <br /> &gt; dump_stack_lvl+0x5d/0x80<br /> &gt; ubsan_epilogue+0x5/0x2b<br /> &gt; __ubsan_handle_out_of_bounds.cold+0x46/0x4b<br /> &gt; ath5k_tasklet_tx+0x4e0/0x560 [ath5k]<br /> &gt; tasklet_action_common+0xb5/0x1c0<br /> <br /> Es real. &amp;#39;ts-&gt;ts_final_idx&amp;#39; puede ser 3 en 5212, así que:<br /> info-&gt;status.rates[ts-&gt;ts_final_idx + 1].idx = -1;<br /> con el array definido como:<br /> struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];<br /> mientras que el tamaño es:<br /> #define IEEE80211_TX_MAX_RATES 4<br /> es de hecho erróneo.<br /> <br /> Establecer este centinela &amp;#39;idx = -1&amp;#39; solo si el índice del array es menor que el tamaño del array. Ya que mac80211 no buscará tasas más allá del tamaño (IEEE80211_TX_MAX_RATES).<br /> <br /> Nota: El efecto de la escritura OOB es insignificante. Simplemente sobrescribe el siguiente miembro de info-&gt;status, es decir, ack_signal.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> pmdomain: mediatek: soluciona el uso después de liberación en scpsys_get_bus_protection_legacy()<br /> <br /> En scpsys_get_bus_protection_legacy(), of_find_node_with_property() devuelve un nodo de dispositivo con su contador de referencias incrementado. La función luego llama a of_node_put(node) antes de verificar si syscon_regmap_lookup_by_phandle() devuelve un error. Si ocurre un error, dev_err_probe() desreferencia el puntero del nodo para imprimir información de diagnóstico, pero la memoria del nodo puede haber sido liberada ya debido a la llamada anterior a of_node_put(), lo que lleva a una vulnerabilidad de uso después de liberación.<br /> <br /> Esto se soluciona moviendo la llamada a of_node_put() después de la verificación de errores, asegurando que el nodo siga siendo válido cuando se accede a él en la ruta de error.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/xe/uapi: Rechazar el índice PAT coh_none para memoria caché de CPU en madvise<br /> <br /> Añadir validación en xe_vm_madvise_ioctl() para rechazar índices PAT con modo de coherencia XE_COH_NONE cuando se aplica a memoria caché de CPU.<br /> <br /> Usar coh_none con búferes en caché de CPU es un problema de seguridad. Cuando el kernel borra páginas antes de la reasignación, la operación de borrado permanece en la caché de la CPU (sucia). La GPU con coh_none puede omitir las cachés de la CPU y leer datos sensibles obsoletos directamente de la DRAM, potencialmente filtrando datos de páginas previamente liberadas de otros procesos.<br /> <br /> Esto se alinea con la validación existente en la ruta vm_bind (xe_vm_bind_ioctl_validate_bo).<br /> <br /> v2(Matthew brost)<br /> - Añadir correcciones<br /> - Mover una impresión de depuración a un lugar mejor<br /> <br /> v3(Matthew Auld)<br /> - Debería ser drm/xe/uapi<br /> - Más Cc<br /> <br /> v4(Shuicheng Lin)<br /> - Corregir problemas de fuga de kmem de paso<br /> <br /> v5<br /> - Eliminar la fuga de kmem porque ha sido fusionada por otro parche<br /> <br /> v6<br /> - Eliminar la corrección que no está relacionada con la corrección actual<br /> <br /> v7<br /> - Sin cambios<br /> <br /> v8<br /> - Rebase<br /> <br /> v9<br /> - Limitar las restricciones a la iGPU<br /> <br /> v10<br /> - Sin cambios<br /> <br /> (seleccionado de la confirmación 016ccdb674b8c899940b3944952c96a6a490d10a)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: renesas: vsp1: Solución a la desreferencia de puntero NULL al descargar el módulo<br /> <br /> Al descargar el módulo en gen 4, se produce una desreferencia de puntero NULL.<br /> Esto es causado por el código de limpieza que llama a vsp1_drm_cleanup() cuando debería estar llamando a vsp1_vspx_cleanup().<br /> <br /> Esto se soluciona al verificar la versión de IP y llamar a la función drm o vspx según corresponda, de la misma manera que lo hace el código de inicialización.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix held lock freed on hfsplus_fill_super()<br /> <br /> hfsplus_fill_super() calls hfs_find_init() to initialize a search<br /> structure, which acquires tree-&gt;tree_lock. If the subsequent call to<br /> hfsplus_cat_build_key() fails, the function jumps to the out_put_root<br /> error label without releasing the lock. The later cleanup path then<br /> frees the tree data structure with the lock still held, triggering a<br /> held lock freed warning.<br /> <br /> Fix this by adding the missing hfs_find_exit(&amp;fd) call before jumping<br /> to the out_put_root error label. This ensures that tree-&gt;tree_lock is<br /> properly released on the error path.<br /> <br /> The bug was originally detected on v6.13-rc1 using an experimental<br /> static analysis tool we are developing, and we have verified that the<br /> issue persists in the latest mainline kernel. The tool is specifically<br /> designed to detect memory management issues. It is currently under active<br /> development and not yet publicly available.<br /> <br /> We confirmed the bug by runtime testing under QEMU with x86_64 defconfig,<br /> lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we<br /> used GDB to dynamically shrink the max_unistr_len parameter to 1 before<br /> hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally<br /> return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and<br /> exercises the faulty error path. The following warning was observed<br /> during mount:<br /> <br /> =========================<br /> WARNING: held lock freed!<br /> 7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted<br /> -------------------------<br /> mount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there!<br /> ffff888103f920b0 (&amp;tree-&gt;tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0<br /> 2 locks held by mount/174:<br /> #0: ffff888103f960e0 (&amp;type-&gt;s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40<br /> #1: ffff888103f920b0 (&amp;tree-&gt;tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0<br /> <br /> stack backtrace:<br /> CPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x82/0xd0<br /> debug_check_no_locks_freed+0x13a/0x180<br /> kfree+0x16b/0x510<br /> ? hfsplus_fill_super+0xcb4/0x18a0<br /> hfsplus_fill_super+0xcb4/0x18a0<br /> ? __pfx_hfsplus_fill_super+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? bdev_open+0x65f/0xc30<br /> ? srso_return_thunk+0x5/0x5f<br /> ? pointer+0x4ce/0xbf0<br /> ? trace_contention_end+0x11c/0x150<br /> ? __pfx_pointer+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? bdev_open+0x79b/0xc30<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? vsnprintf+0x6da/0x1270<br /> ? srso_return_thunk+0x5/0x5f<br /> ? __mutex_unlock_slowpath+0x157/0x740<br /> ? __pfx_vsnprintf+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? mark_held_locks+0x49/0x80<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? irqentry_exit+0x17b/0x5e0<br /> ? trace_irq_disable.constprop.0+0x116/0x150<br /> ? __pfx_hfsplus_fill_super+0x10/0x10<br /> ? __pfx_hfsplus_fill_super+0x10/0x10<br /> get_tree_bdev_flags+0x302/0x580<br /> ? __pfx_get_tree_bdev_flags+0x10/0x10<br /> ? vfs_parse_fs_qstr+0x129/0x1a0<br /> ? __pfx_vfs_parse_fs_qstr+0x3/0x10<br /> vfs_get_tree+0x89/0x320<br /> fc_mount+0x10/0x1d0<br /> path_mount+0x5c5/0x21c0<br /> ? __pfx_path_mount+0x10/0x10<br /> ? trace_irq_enable.constprop.0+0x116/0x150<br /> ? trace_irq_enable.constprop.0+0x116/0x150<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? kmem_cache_free+0x307/0x540<br /> ? user_path_at+0x51/0x60<br /> ? __x64_sys_mount+0x212/0x280<br /> ? srso_return_thunk+0x5/0x5f<br /> __x64_sys_mount+0x212/0x280<br /> ? __pfx___x64_sys_mount+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? trace_irq_enable.constprop.0+0x116/0x150<br /> ? srso_return_thunk+0x5/0x5f<br /> do_syscall_64+0x111/0x680<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ffacad55eae<br /> Code: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8<br /> RSP: 002b<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: s3c64xx: corrige desreferencia NULL al desvincular el controlador<br /> <br /> Un cambio que movió la asignación del canal DMA de probe() de vuelta a s3c64xx_spi_prepare_transfer() no eliminó la desasignación correspondiente de remove().<br /> <br /> Eliminar la liberación errónea del canal DMA de remove() para evitar activar una desreferencia de puntero NULL al desvincular el controlador.<br /> <br /> Este problema fue señalado por Sashiko al revisar una corrección de desregistro del controlador.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: libwx: usar request_irq para interrupción miscelánea de VF<br /> <br /> Actualmente, se usa request_threaded_irq() con un gestor primario pero un gestor en hilo NULL, mientras también se establece la bandera IRQF_ONESHOT. Esta combinación específica dispara una ADVERTENCIA desde el commit aef30c8d569c (&amp;#39;genirq: Advertir sobre el uso de IRQF_ONESHOT sin un gestor en hilo&amp;#39;).<br /> <br /> ADVERTENCIA: kernel/irq/manage.c:1502 en __setup_irq+0x4fa/0x760<br /> <br /> Se corrige el problema cambiando a request_irq(), que es la interfaz apropiada o un gestor de interrupciones no en hilo, y eliminando la bandera IRQF_ONESHOT innecesaria.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> pseries/papr-hvpipe: Corregir condición de carrera con el gestor de interrupciones<br /> <br /> Mientras se ejecuta el gestor -&gt;ioctl o el gestor -&gt;release, si se dispara una interrupción en la misma CPU, entonces podemos entrar en un interbloqueo.<br /> <br /> Este parche corrige ambos gestores para usar las versiones spin_lock_irq{save|restore} del bloqueo para prevenir este interbloqueo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: topcliff-pch: corrección de uso después de liberación al desvincular<br /> <br /> Dar al controlador una oportunidad de vaciar su cola antes de liberar los búferes DMA al desvincular el controlador.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> selinux: permitir múltiples aperturas de /sys/fs/selinux/policy<br /> <br /> Actualmente solo puede haber una única apertura de /sys/fs/selinux/policy en cualquier momento. Esto permite a cualquier proceso bloquear a cualquier otro proceso de leer la política del kernel. La motivación original parece haber sido una mezcla de prevenir una vista inconsistente del tamaño de la política y evitar que el espacio de usuario asigne memoria del kernel sin límites, pero esto es, discutiblemente, igual de malo. Eliminar el indicador policy_opened y reducir la sección crítica en la que se mantiene el mutex de la política. Mientras estamos haciendo cambios aquí, eliminar un par de BUG_ONs superfluos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> isofs: validar la extensión de continuación Rock Ridge CE contra el tamaño del volumen<br /> <br /> rock_continue() lee rs-&gt;cont_extent textualmente del registro Rock Ridge CE y lo pasa a sb_bread() sin verificar que el número de bloque esté dentro del volumen ISO 9660 montado. El commit e595447e177b (&amp;#39;[PATCH] rock.c: handle corrupted directories&amp;#39;) añadió el rechazo de cont_offset y cont_size para la continuación CE pero no validó el número de bloque de la extensión en sí. El commit f54e18f1b831 (&amp;#39;isofs: Fix infinite looping over CE entries&amp;#39;) más tarde limitó la longitud de la cadena CE a RR_MAX_CE_ENTRIES = 32 pero de nuevo dejó el número de bloque sin verificar.<br /> <br /> Con un ISO manipulado montado vía udisks2 (montaje automático óptico de escritorio) o vía montaje CAP_SYS_ADMIN, rs-&gt;cont_extent puede, por lo tanto, apuntar a un bloque fuera de rango o a bloques pertenecientes a un sistema de archivos adyacente en el mismo dispositivo de bloques. sb_bread() en un bloque fuera de rango devuelve NULL limpiamente vía la ruta EIO de la capa de bloques, por lo que no hay violación de seguridad de memoria. Para lecturas dentro de rango de datos de sistemas de archivos adyacentes, el búfer CE se analiza como registros Rock Ridge y solo el texto de los subregistros SL llega al espacio de usuario a través de readlink(), lo que hace que el canal de fuga de información sea estrecho y difícil de exploit; aún así, rechazar el CE malformado directamente coincide con la forma de rechazo ya presente en la misma función para cont_offset y cont_size.<br /> <br /> Añadir una verificación de límites ISOFS_SB(sb)-&gt;s_nzones a rock_continue() junto al rechazo existente de offset/size, imprimiendo el mismo aviso de entrada de directorio corrupta.