Vulnerabilidades

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: 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: media: i2c: max9286: arregla el error del kernel al eliminar el módulo Al eliminar el módulo max9286 obtenemos un error del kernel: No se puede gestionar la solicitud de paginación del kernel en la dirección virtual 000000aa00000094 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000 [000000aa00000094] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec CPU: 2 PID: 713 Comm: rmmod Tainted: G C 5.15.5-00057-gaebcd29c8ed7-dirty #5 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : i2c_mux_del_adapters+0x24/0xf0 lr : max9286_remove+0x28/0xd0 [max9286] sp : ffff800013a9bbf0 x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000 x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8 x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000 Call trace: i2c_mux_del_adapters+0x24/0xf0 max9286_remove+0x28/0xd0 [max9286] i2c_device_remove+0x40/0x110 __device_release_driver+0x188/0x234 driver_detach+0xc4/0x150 bus_remove_driver+0x60/0xe0 driver_unregister+0x34/0x64 i2c_del_driver+0x58/0xa0 max9286_i2c_driver_exit+0x1c/0x490 [max9286] __arm64_sys_delete_module+0x194/0x260 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xd4/0xfc do_el0_svc+0x2c/0x94 el0_svc+0x28/0x80 el0t_64_sync_handler+0xa8/0x130 el0t_64_sync+0x1a0/0x1a4 The Oops happens because the I2C client data does not point to max9286_priv anymore but to v4l2_subdev. El cambio ocurrió en max9286_init() que llama a v4l2_i2c_subdev_init() más adelante... Además de arreglar la función max9286_remove(), elimine la llamada a i2c_set_clientdata() en max9286_probe(), para evitar confusiones, y haga los cambios necesarios en max9286_init() para que no tenga que usar i2c_get_clientdata() para obtener el puntero a priv.

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: wl1251: asignar dinámicamente memoria utilizada para DMA Con la introducción de pilas vmap'ed, los parámetros de pila ya no se pueden utilizar para DMA y ahora provoca un pánico del kernel. Sucede en varios lugares para wl1251 (por ejemplo, cuando se accede a través de SDIO), lo que lo hace inutilizable en, por ejemplo, OpenPandora. Solucionamos esto asignando búferes temporales o utilizando wl1251_read32(). Probado en v5.18-rc5 con OpenPandora.

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFC: NULL en dev-&amp;gt;rfkill para evitar UAF Commit 3e3b5dfcd16a ("NFC: reordenar la lógica en nfc_{un,}register_device") supone que device_is_registered() en la función nfc_dev_up() ayudará a comprobar cuándo se anula el registro de rfkill. Sin embargo, esta comprobación solo tiene efecto cuando se realiza device_del(&amp;amp;dev-&amp;gt;dev) en nfc_unregister_device(). Por lo tanto, el objeto rfkill aún puede desreferenciarse. El rastro de falla en el kernel más reciente (5.18-rc2): [ 68.760105] ======================================================================= [ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750 [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313 [ 68.760756] [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4 [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 68.760756] Call Trace: [ 68.760756] [ 68.760756] dump_stack_lvl+0x57/0x7d [ 68.760756] print_report.cold+0x5e/0x5db [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] kasan_report+0xbe/0x1c0 [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] __lock_acquire+0x3ec1/0x6750 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? register_lock_class+0x18d0/0x18d0 [ 68.760756] lock_acquire+0x1ac/0x4f0 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0 [ 68.760756] ? nla_get_range_signed+0x540/0x540 [ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50 [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] rfkill_blocked+0xe/0x60 [ 68.760756] nfc_dev_up+0x84/0x260 [ 68.760756] nfc_genl_dev_up+0x90/0xe0 [ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0 [ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230 [ 68.760756] ? security_capable+0x51/0x90 [ 68.760756] genl_rcv_msg+0x280/0x500 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? lock_acquire+0x1ac/0x4f0 [ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] netlink_rcv_skb+0x11b/0x340 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? netlink_ack+0x9c0/0x9c0 [ 68.760756] ? netlink_deliver_tap+0x136/0xb00 [ 68.760756] genl_rcv+0x1f/0x30 [ 68.760756] netlink_unicast+0x430/0x710 [ 68.760756] ? memset+0x20/0x40 [ 68.760756] ? netlink_attachskb+0x740/0x740 [ 68.760756] ? __build_skb_around+0x1f4/0x2a0 [ 68.760756] netlink_sendmsg+0x75d/0xc00 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] sock_sendmsg+0xdf/0x110 [ 68.760756] __sys_sendto+0x19e/0x270 [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0 [ 68.760756] ? fd_install+0x178/0x4c0 [ 68.760756] ? fd_install+0x195/0x4c0 [ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0 [ 68.760756] __x64_sys_sendto+0xd8/0x1b0 [ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130 [ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50 [ 68.760756] do_syscall_64+0x3b/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 68.760756] RIP: 0033:0x7f67fb50e6b3 ... [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3 [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003 [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003 [ 68.760756] [ 68.760756] [ 68.760756] Allocated by task 279: [ 68.760756] kasan_save_stack+0x1e/0x40 [ ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mediatek: Agregar funciones de devolución de llamada de registro/cancelación de vblank Encontramos un problema de pánico del kernel que indicaba que los datos de devolución de llamada serían NULL cuando se usaban en el controlador de irq de ovl. Hay un problema de sincronización entre mtk_disp_ovl_irq_handler() y mtk_ovl_disable_vblank(). Para resolver este problema, usamos el flujo para registrar/cancelar el cb de vblank: - Registrar la función de devolución de llamada y los datos de devolución de llamada cuando se crea crtc. - Cancelar la función de devolución de llamada y los datos de devolución de llamada cuando se destruye crtc. Con esta solución, podemos asegurar que los datos de devolución de llamada no serían NULL cuando se deshabilita vblank.