Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: Se corrige la gestión de errores en la llamada mt8173_max98090_dev_probe of_node_put(platform_node) para evitar la pérdida de recuento de referencias en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: cs35l41: Se corrige un acceso fuera de los límites en otp_packed_element_t. CS35L41_NUM_OTP_ELEM es 100, pero solo se definen 99 entradas en la matriz otp_map_1/2[CS35L41_NUM_OTP_ELEM], esto hará que UBSAN informe una advertencia de cambio fuera de los límites en cs35l41_otp_unpack() ya que la última entrada en la matriz dará como resultado GENMASK(-1, 0). UBSAN informa este problema: UBSAN: cambio fuera de los límites en /home/hwang4/build/jammy/jammy/sound/soc/codecs/cs35l41-lib.c:836:8 El exponente de cambio 64 es demasiado grande para el tipo de 64 bits 'long unsigned int' CPU: 10 PID: 595 Comm: systemd-udevd No contaminado 5.15.0-23-generic #23 Nombre del hardware: LENOVO \x02MFG_IN_GO/\x02MFG_IN_GO, BIOS N3GET19W (1.00) 03/11/2022 Seguimiento de llamadas: show_stack+0x52/0x58 dump_stack_lvl+0x4a/0x5f dump_stack+0x10/0x12 cs35l41_hda_i2c_probe+0x65/0x90 [snd_hda_scodec_cs35l41_i2c] ? cs35l41_hda_i2c_remove+0x20/0x20 [snd_hda_scodec_cs35l41_i2c] sonda de dispositivo i2c+0x252/0x2b0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: siempre comprobar los valores del puntero VSI de VF La función ice_get_vf_vsi puede devolver NULL en algunos casos, como si se trataran mensajes durante un reinicio en el que se elimina y se vuelve a crear el VSI. Varios lugares del controlador no se molestan en comprobar si este puntero VSI es válido. Las herramientas de análisis estático pueden informar problemas porque detectan rutas en las que se podría desreferenciar un puntero potencialmente NULL. Solucione esto comprobando el valor de retorno de ice_get_vf_vsi en todas partes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: Se corrige la falta de of_node_put en mt2701_wm8960_machine_probe. Este puntero de nodo es devuelto por of_parse_phandle() con refcount incrementado en esta función. Se llama a of_node_put() para evitar la fuga de refcount.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: ipc3-topology: get_control_data correcto para payload que no sea de bytes Es posible crear una topología donde sof_get_control_data() haría acceso fuera de los límites porque espera que solo se llame cuando el payload sea de tipo bytes. Confusamente también maneja otros tipos de controles, pero la implementación del análisis del payload solo es válida para bytes. Corrija el código para contar los controles que no sean de bytes y en lugar de almacenar un puntero a sof_abi_hdr en sof_widget_data (que solo es válido para bytes), almacene el puntero a los datos en sí y agregue un nuevo miembro para guardar el tamaño de los datos. En el caso de controles que no sean de bytes, almacenamos el puntero al chanv en sí, que es solo una matriz de valores al final. En el caso del control de bytes, elimine la comprobación incorrecta cdata->data (wdata[i].pdata) contra NULL ya que es incorrecta e inválida en este contexto. Los datos apuntan al final de la estructura cdata, por lo que nunca deben ser nulos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: defio: corrige la corrupción de la lista de páginas. Fácilmente se llega a la siguiente corrupción de lista: == list_add corruption. prev->next should be next (ffffffffc0ceb090), but was ffffec604507edc8. (prev=ffffec604507edc8). WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26 __list_add_valid+0x53/0x80 CPU: 65 PID: 3959 Comm: fbdev Tainted: G U RIP: 0010:__list_add_valid+0x53/0x80 Call Trace: fb_deferred_io_mkwrite+0xea/0x150 do_page_mkwrite+0x57/0xc0 do_wp_page+0x278/0x2f0 __handle_mm_fault+0xdc2/0x1590 handle_mm_fault+0xdd/0x2c0 do_user_addr_fault+0x1d3/0x650 exc_page_fault+0x77/0x180 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x7fd98fc8fad1 == Averigüe que la ejecución ocurre cuando un proceso agrega &page->lru a la cola de la lista de páginas en fb_deferred_io_mkwrite(), otro proceso está reinicializando la misma &page->lru en fb_deferred_io_fault(), que no está protegida por el bloqueo. Esta solución consiste en inicializar todas las listas de páginas una vez durante la inicialización, no solo corrige la corrupción de la lista, sino que también evita que INIT_LIST_HEAD() se ejecute de manera redundante. V2: cambie "int i" por "unsigned int i" (Geert Uytterhoeven)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath10k: omitir ath10k_halt durante la suspensión para el estado del controlador REINICIO Se observa un doble bloqueo libre cuando la recuperación de FW (causada por el tiempo de espera/bloqueo de wmi) es seguida por un evento de suspensión inmediata. La recuperación de FW es activada por ath10k_core_restart() que llama a la limpieza del controlador a través de ath10k_halt(). Cuando el evento de suspensión ocurre entre la recuperación de FW, el hilo de trabajo de reinicio se pone en estado congelado hasta que se completa la suspensión. El evento de suspensión activa ath10k_stop() que nuevamente activa ath10k_halt() La doble invocación de ath10k_halt() hace que ath10k_htt_rx_free() se llame dos veces (Nota: ath10k_htt_rx_alloc no fue llamado por el hilo de trabajo de reinicio debido a su estado congelado), lo que causa el bloqueo. Para solucionar esto, durante el flujo de suspensión, omite la llamada a ath10k_halt() en ath10k_stop() cuando el estado actual del controlador sea ATH10K_STATE_RESTARTING. Además, para el estado del controlador ATH10K_STATE_RESTARTING, llama a ath10k_wait_for_suspend() en ath10k_stop(). Esto se debe a que la llamada a ath10k_wait_for_suspend() se omite más adelante en [ath10k_halt() > ath10k_core_stop()] para el estado del controlador ATH10K_STATE_RESTARTING. El hilo de trabajo de reinicio congelado se cancelará durante la reanudación cuando el dispositivo salga de la suspensión. A continuación se muestra la pila de fallas como referencia: [ 428.469167] ------------[ cortar aquí ]------------ [ 428.469180] kernel BUG at mm/slub.c:4150! [ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 428.469219] Workqueue: events_unbound async_run_entry_fn [ 428.469230] RIP: 0010:kfree+0x319/0x31b [ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246 [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000 [ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000 [ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000 [ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 428.469285] Call Trace: [ 428.469295] ? dma_free_attrs+0x5f/0x7d [ 428.469320] ath10k_core_stop+0x5b/0x6f [ 428.469336] ath10k_halt+0x126/0x177 [ 428.469352] ath10k_stop+0x41/0x7e [ 428.469387] drv_stop+0x88/0x10e [ 428.469410] __ieee80211_suspend+0x297/0x411 [ 428.469441] rdev_suspend+0x6e/0xd0 [ 428.469462] wiphy_suspend+0xb1/0x105 [ 428.469483] ? name_show+0x2d/0x2d [ 428.469490] dpm_run_callback+0x8c/0x126 [ 428.469511] ? name_show+0x2d/0x2d [ 428.469517] __device_suspend+0x2e7/0x41b [ 428.469523] async_suspend+0x1f/0x93 [ 428.469529] async_run_entry_fn+0x3d/0xd1 [ 428.469535] process_one_work+0x1b1/0x329 [ 428.469541] worker_thread+0x213/0x372 [ 428.469547] kthread+0x150/0x15f [ 428.469552] ? pr_cont_work+0x58/0x58 [ 428.469558] ? kthread_blkcg+0x31/0x31 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm: corrige desreferencias de puntero nulo sin iommu. Comprueba si 'aspace' está configurado antes de usarlo, ya que permanecerá nulo sin IOMMU, como en msm8974.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet: Ejecutar unregister_netdev() antes unbind() de nuevo El commit 2c9d6c2b871d ("usbnet: run unbind() antes unregister_netdev()") buscaba corregir un uso después de liberación (use-after-free) al desconectar los adaptadores USB Ethernet. Resulta que es necesaria una corrección diferente para abordar el problema: https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ Por lo tanto, el commit no era necesario. El commit hizo que la vinculación y desvinculación de USB Ethernet fuera asimétrica: antes, usbnet_probe() primero invocaba la devolución de llamada -&amp;amp;gtbind() y luego register_netdev(). usbnet_disconnect() reflejó eso al invocar primero unregister_netdev() y luego -&amp;amp;gtunbind(). Desde el commit, el orden en usbnet_disconnect() se invierte y ya no refleja usbnet_probe(). Una consecuencia es que un PHY desconectado (y detenido) en -&amp;amp;gtunbind() se detiene luego una vez más por unregister_netdev() ya que cierra el netdev antes de anular el registro. Eso requiere una contorsión en -&amp;amp;gtstop() porque el PHY solo se puede detener si no se ha desconectado ya. Revertir el commit permite hacer que la llamada a phy_stop() sea incondicional en -&amp;amp;gtstop().<br />

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: rga: corrige posible pérdida de memoria en rga_probe rga-&amp;gt;m2m_dev debe liberarse cuando rga_probe falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath9k_htc: se corrige el posible acceso fuera de los límites con rxstatus-&amp;gt;rs_keyix no válido. "rxstatus-&amp;gt;rs_keyix" finalmente se pasa a test_bit(), por lo que debemos asegurarnos de que esté dentro del mapa de bits. drivers/net/wireless/ath/ath9k/common.c:46 Error ath9k_cmn_rx_accept(): se pasan datos no confiables &amp;#39;rx_stats-&amp;gt;rs_keyix&amp;#39; a &amp;#39;test_bit()&amp;#39;

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Inhibit aborta si se inserta un enchufe de loopback externo Después de ejecutar una prueba de loopback externa corta, cuando se quita el loopback externo y se inserta un cable normal que está conectado directamente a un dispositivo de destino, el sistema falla en la rutina llpfc_set_rrq_active(). Cuando se insertó el loopback, se transmitió un FLOGI. Mientras estamos en loopback, recibimos la solicitud FLOGI. El FLOGI se ABTS ya que reconocemos el mismo wppn, por lo que entendemos que es un loopback. Sin embargo, como el ABTS envía información de dirección, el puerto no está configurado en (fffffe), el ABTS se descarta en el cable. Se ejecuta una prueba de loopback corta de 1 trama y se completa antes de que el ABTS se agote. El looback se desconecta y el nuevo cable se enchufa, y se produce un FLOGI al nuevo dispositivo y se completa. Debido a una confusión en el recuento de referencias, la finalización del nuevo FLOGI libera el ndlp de la estructura. Luego, el ABTS original se completa y hace referencia al ndlp liberado, lo que genera el error. Se corrige no operando el ABTS cuando está en modo de bucle invertido (se descartará de todos modos). Se agregó una bandera para rastrear el modo para reconocer cuándo se debe no operar.