Vulnerabilidades

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.

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: 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: drm/msm/disp/dpu1: establecer la configuración de hardware de vbif en NULL para evitar su uso después de liberar memoria durante la reanudación del tiempo de ejecución de pm ERROR: No se puede gestionar la solicitud de paginación del kernel en la dirección virtual 006b6b6b6b6b6be3 Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c Patchwork: https://patchwork.freedesktop.org/patch/483255/ [DB: fixed Fixes tag]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/mdp5: Devuelve un código de error en mdp5_pipe_release cuando se detecta un bloqueo mdp5_get_global_state corre el riesgo de alcanzar un -EDEADLK al adquirir el bloqueo modeset, pero actualmente mdp5_pipe_release no verifica si se devuelve un error. Debido a esto, existe la posibilidad de que mdp5_pipe_release alcance un error de desreferencia NULL. Para evitar esto, hagamos que mdp5_pipe_release verifique si mdp5_get_global_state devuelve un error y propague ese error. Cambios desde v1: - Declaración separada e inicialización de *new_state para evitar advertencias del compilador - Se corrigieron algunos errores ortográficos en el mensaje de confirmación Cambios desde v2: - Devuelve 0 en caso de que hwpipe sea NULL, ya que esto se considera un comportamiento normal - Se agregó el segundo parche en serie para corregir un problema de desreferencia NULL similar en mdp5_mixer_release Patchwork: https://patchwork.freedesktop.org/patch/485179/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/rockchip: vop: corrige posible null-ptr-deref en vop_bind() Provocará null-ptr-deref en resource_size(), si platform_get_resource() devuelve NULL, mueve la llamada a resource_size() después de devm_ioremap_resource() que comprobará &amp;#39;res&amp;#39; para evitar null-ptr-deref.