Vulnerabilidades

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: 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: 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: HID: elan: Se corrige una posible doble liberación en elan_input_configured &amp;#39;input&amp;#39; es un recurso administrado asignado con devm_input_allocate_device(), por lo que no es necesario llamar a input_free_device() explícitamente o habrá una doble liberación. Según la documentación de devm_input_allocate_device(): * Los dispositivos de entrada administrados no necesitan ser desregistrados explícitamente o * liberados ya que se hará automáticamente cuando el dispositivo propietario se desvincule de * su controlador (o la vinculación falle).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulador: da9121: Fix uninit-value in da9121_assign_chip_model() KASAN report slab-out-of-bounds in __regmap_init as follows: BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841 Read of size 1 at addr ffff88803678cdf1 by task xrun/9137 CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88 print_report.cold+0xcd/0x69b mm/kasan/report.c:313 kasan_report+0x8e/0xc0 mm/kasan/report.c:491 __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841 __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266 __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394 da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039 i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563 This happend when da9121 device is probe by da9121_i2c_id, but with invalid dts. Thus, chip-&amp;gt;subvariant_id is set to -EINVAL, and later da9121_assign_chip_model() will access &amp;#39;regmap&amp;#39; without init it. Fix it by return -EINVAL from da9121_assign_chip_model() if &amp;#39;chip-&amp;gt;subvariant_id&amp;#39; is invalid.

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: drm/msm: corrige desreferencias de puntero nulo sin iommu. Comprueba si &amp;#39;aspace&amp;#39; 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&amp;#39;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: 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: 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.