Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Se corrige memcpy() fuera de los límite durante ethtool -w Al recuperar el volcado de núcleo de FW con ethtool, a veces puede causar corrupción de memoria: ERROR: KFENCE: corrupción de memoria en __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] Memoria corrupta en 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (en kfence-#45): __bnxt_get_coredump+0x3ef/0x670 [bnxt_es] ethtool_get_dump_data+0xdc/0x1a0 __dev_ethtool+0xa1e/0x1af0 dev_ethtool+0xa8/0x170 dev_ioctl+0x1b5/0x580 sock_do_ioctl+0xab/0xf0 sock_ioctl+0x1ce/0x2e0 __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x78/0x80 ... Esto sucede al copiar la lista de segmentos del volcado de núcleo en bnxt_hwrm_dbg_dma_data() con el comando de firmware HWRM_DBG_COREDUMP_LIST. El búfer info->dest_buf se asigna según la cantidad de segmentos de volcado de núcleo devueltos por el firmware. El firmware procesa la lista de segmentos mediante DMA y devuelve su longitud. El controlador copia esta lista de segmentos procesada mediante DMA en info->dest_buf. En algunos casos, esta longitud de DMA puede superar la longitud de info->dest_buf y causar el error mencionado. Para solucionarlo, limite la longitud de la copia para que no supere la longitud de info->dest_buf. Los datos DMA adicionales no contienen información útil. Esta ruta de código es compartida por los comandos de firmware HWRM_DBG_COREDUMP_LIST y HWRM_DBG_COREDUMP_RETRIEVE. El almacenamiento en búfer es diferente para estos dos comandos de firmware. Para simplificar la lógica, necesitamos mover la línea para ajustar la longitud del búfer para HWRM_DBG_COREDUMP_RETRIEVE hacia arriba, de modo que la nueva verificación para limitar la longitud de la copia funcione para ambos comandos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: comprobar el valor del puntero VF VSI en ice_vc_add_fdir_fltr() Como se menciona en el commit baeb705fd6a7 ("ice: siempre comprobar los valores del puntero VF VSI"), debemos realizar una verificación de puntero nulo en el valor de retorno de ice_get_vf_vsi() antes de usarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: qfq: Se corrige la adición doble de lista en una clase con netem como qdisc secundaria. Como se describe en el informe de Gerrard [1], existen casos de uso en los que una qdisc secundaria netem hará que la devolución de llamada de encolado de la qdisc primaria sea reentrante. En el caso de qfq, no habrá un UAF, pero el código agregará el mismo clasificador a la lista dos veces, lo que causará corrupción de memoria. Este parche verifica si la clase ya se agregó a la lista agg->active (cl_is_active) antes de realizar la adición para atender el caso reentrante. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: ets: Se corrige la adición doble de lista en la clase con netem como qdisc secundaria. Como se describe en el informe de Gerrard [1], existen casos de uso en los que una qdisc secundaria netem hará que la devolución de llamada de encolado de la qdisc primaria sea reentrante. En el caso de ets, no habrá un UAF, pero el código agregará el mismo clasificador a la lista dos veces, lo que causará corrupción de memoria. Además de verificar que qlen sea cero, este parche verifica si la clase ya se agregó a active_list (cl_is_active) antes de realizar la adición para atender el caso reentrante. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: plfxlc: Eliminar aserción errónea en plfxlc_mac_release. plfxlc_mac_release() afirma que mac->lock se mantiene. Esta aserción es incorrecta, ya que, incluso si fuera posible, no sería el comportamiento válido. La función se utiliza cuando falla la sonda o después de desconectar el dispositivo. En ambos casos, mac->lock no se puede mantener, ya que el controlador no está trabajando con el dispositivo en ese momento. Todas las funciones que usan mac->lock lo desbloquean justo después de mantenerlo. Tampoco es necesario mantener mac->lock para plfxlc_mac_release(), ya que los datos de mac no se ven afectados, excepto mac->flags, que se modifica automáticamente. Este error genera la siguiente advertencia: ================================================================== ADVERTENCIA: CPU: 0 PID: 127 en drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0 Módulos vinculados: CPU: 0 PID: 127 Comm: kworker/0:2 No contaminado 6.1.124-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: usb_hub_wq hub_event RIP: 0010:plfxlc_mac_release+0x7d/0xa0 controladores/red/inalámbrico/purelifi/plfxlc/mac.c:106 Rastreo de llamadas: probe+0x941/0xbd0 drivers/net/wireless/purelifi/plfxlc/usb.c:694 usb_probe_interface+0x5c0/0xaf0 drivers/usb/core/driver.c:396 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_set_configuration+0x19dd/0x2020 drivers/usb/core/message.c:2165 usb_generic_driver_probe+0x84/0x140 drivers/usb/core/generic.c:238 usb_probe_device+0x130/0x260 drivers/usb/core/driver.c:293 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_new_device+0xbdd/0x18f0 drivers/usb/core/hub.c:2620 hub_port_connect drivers/usb/core/hub.c:5477 [inline] hub_port_connect_change drivers/usb/core/hub.c:5617 [inline] port_event drivers/usb/core/hub.c:5773 [inline] hub_event+0x2efe/0x5730 drivers/usb/core/hub.c:5855 process_one_work+0x8a9/0x11d0 kernel/workqueue.c:2292 worker_thread+0xa47/0x1200 kernel/workqueue.c:2439 kthread+0x28d/0x320 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 ================================================================ Encontrado por el Centro de verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc64/ftrace: se corrige la carga de módulos sin entradas de función parcheables. get_stubs_size asume que siempre debe haber al menos una entrada de función parcheable, lo cual no siempre ocurre (módulos que exportan datos, pero no código); de lo contrario, devuelve -ENOEXEC y, por lo tanto, el encabezado de sección sh_size se establece en ese valor. Durante module_memory_alloc(), el tamaño se pasa a execmem_alloc() tras la alineación de página y, por lo tanto, se establece en cero, lo que provocará un error en la asignación (y, por lo tanto, en la carga del módulo), ya que __vmalloc_node_range() busca asignaciones de tamaño cero y devuelve null: [115.466896] module_64: cast_common: no contiene __patchable_function_entries. [ 115.469189] ------------[ cortar aquí ]------------ [ 115.469496] ADVERTENCIA: CPU: 0 PID: 274 en mm/vmalloc.c:3778 __vmalloc_node_range_noprof+0x8b4/0x8f0 ... [ 115.478574] ---[ fin del seguimiento 0000000000000000 ]--- [ 115.479545] execmem: no se puede asignar memoria Solucione esto eliminando la verificación por completo, ya que de todos modos no es útil propagar esto como un error hacia arriba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrección del problema "use-after-free" al cerrar sesión. El objeto sess->user puede estar siendo utilizado por otro hilo, por ejemplo, si otra conexión ha enviado una solicitud de configuración de sesión para enlazarse a la sesión que se está liberando. El controlador de esa conexión podría estar en la función smb2_sess_setup, que utiliza sess->user.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu: Se corrigen dos problemas en iommu_copy_struct_from_user() En la revisión del asistente iommu_copy_struct_to_user(), Matt señaló que se debe rechazar un puntero NULL antes de desreferenciarlo: https://lore.kernel.org/all/86881827-8E2D-461C-BDA3-FA8FD14C343C@nvidia.com Y Alok señaló un error tipográfico al mismo tiempo: https://lore.kernel.org/all/480536af-6830-43ce-a327-adbd13dc3f1d@oracle.com Dado que ambos problemas se copiaron de iommu_copy_struct_from_user(), corríjalos primero en el encabezado actual.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/qcom-mpm: Evita un bloqueo al intentar gestionar GPIO sin activación. En los chipsets Qualcomm, no todos los GPIO tienen capacidad de activación. Estos GPIO no tienen un pin MPM correspondiente y no deben gestionarse dentro del controlador MPM. La jerarquía del dominio IRQ siempre se aplica, por lo que es necesario desconectarla explícitamente. El controlador pinctrl-msm los marca con GPIO_NO_WAKE_IRQ. qcom-pdc cuenta con una comprobación para esto, pero irq-qcom-mpm actualmente no la tiene. Esto está causando fallos al configurar interrupciones para GPIO que no son de activación: root@rb1:~# gpiomon -c gpiochip1 10 irq: IRQ159: recortar jerarquía de :soc@0:interrupt-controller@f200000-1 No se puede manejar la solicitud de paginación del núcleo en la dirección virtual ffff8000a1dc3820 Nombre del hardware: Qualcomm Technologies, Inc. Robotics RB1 (DT) pc: mpm_set_type+0x80/0xcc lr: mpm_set_type+0x5c/0xcc Rastreo de llamadas: mpm_set_type+0x80/0xcc (P) qcom_mpm_set_type+0x64/0x158 irq_chip_set_type_parent+0x20/0x38 msm_gpio_irq_set_type+0x50/0x530 Solucione esto copiando la comprobación de GPIO_NO_WAKE_IRQ desde qcom-pdc.c, de modo que MPM se elimine por completo de la jerarquía para los GPIO que no son de activación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm: corrección de copia tras los límites de la matriz src. La confirmación afectada copió a argv el tamaño del argv reasignado, en lugar del tamaño de old_argv, leyendo y copiando así desde memoria asignada más allá de la de old_argv. Se detectó el siguiente error BUG_ON: [3.038929][T1] ¡Error del kernel en lib/string_helpers.c:1040! [ 3.039147][ T1] Error interno: Ups - ERROR: 00000000f2000800 [#1] SMP ... [ 3.056489][ T1] Call trace: [ 3.056591][ T1] __fortify_panic+0x10/0x18 (P) [ 3.056773][ T1] dm_split_args+0x20c/0x210 [ 3.056942][ T1] dm_table_add_target+0x13c/0x360 [ 3.057132][ T1] table_load+0x110/0x3ac [ 3.057292][ T1] dm_ctl_ioctl+0x424/0x56c [ 3.057457][ T1] __arm64_sys_ioctl+0xa8/0xec [ 3.057634][ T1] invoke_syscall+0x58/0x10c [ 3.057804][ T1] el0_svc_common+0xa8/0xdc [ 3.057970][ T1] do_el0_svc+0x1c/0x28 [ 3.058123][ T1] el0_svc+0x50/0xac [ 3.058266][ T1] el0t_64_sync_handler+0x60/0xc4 [ 3.058452][ T1] el0t_64_sync+0x1b0/0x1b4 [ 3.058620][ T1] Code: f800865e a9bf7bfd 910003fd 941f48aa (d4210000) [ 3.058897][ T1] ---[ end trace 0000000000000000 ]--- [ 3.059083][ T1] Pánico del kernel - no sincroniza: Oops - ERROR: Excepción fatal. Corríjalo copiando el tamaño de src, y no el tamaño de dst, como estaba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se corrige el problema de slab-use-after-free en HDCP. El código HDCP en amdgpu_dm_hdcp.c copia punteros a objetos amdgpu_dm_connector sin incrementar el recuento de referencias de kref. Al usar una base USB-C y desconectarla, se liberan los objetos amdgpu_dm_connector correspondientes, lo que crea punteros colgantes en el código HDCP. Cuando se vuelve a conectar el dock, los punteros colgantes se desreferencian, lo que da como resultado un slab-use-after-free: [ 66.775837] ERROR: KASAN: slab-use-after-free en event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.776171] Lectura de tamaño 4 en la dirección ffff888127804120 por la tarea kworker/0:1/10 [ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 No contaminado 6.14.0-rc7-00180-g54505f727a38-dirty #233 [ 66.776183] Nombre del hardware: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 18/12/2024 [ 66.776186] Cola de trabajo: eventos event_property_validate [amdgpu] [ 66.776494] Seguimiento de llamadas: [ 66.776496] [ 66.776497] dump_stack_lvl+0x70/0xa0 [ 66.776504] print_report+0x175/0x555 [ 66.776507] ? __virt_addr_valid+0x243/0x450 [ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0 [ 66.776515] kasan_report+0xeb/0x1c0 [ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.777121] __asan_report_load4_noabort+0x14/0x20 [ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.777342] ? __lock_acquire+0x6b40/0x6b40 [ 66.777347] ? enable_assr+0x250/0x250 [amdgpu] [ 66.777571] process_one_work+0x86b/0x1510 [ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0 [ 66.777578] ? assign_work+0x16b/0x280 [ 66.777580] ? lock_is_held_type+0xa3/0x130 [ 66.777583] worker_thread+0x5c0/0xfa0 [ 66.777587] ? process_one_work+0x1510/0x1510 [ 66.777588] kthread+0x3a2/0x840 [ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777594] ? trace_hardirqs_on+0x4f/0x60 [ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60 [ 66.777599] ? calculate_sigpending+0x77/0xa0 [ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777605] ret_from_fork+0x40/0x90 [ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777609] ret_from_fork_asm+0x11/0x20 [ 66.777614] [ 66.777643] Asignado por la tarea 10: [ 66.777646] kasan_save_stack+0x39/0x60 [ 66.777649] kasan_save_track+0x14/0x40 [ 66.777652] kasan_save_alloc_info+0x37/0x50 [ 66.777655] __kasan_kmalloc+0xbb/0xc0 [ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0 [ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu] [ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper] [ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper] [ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper] [ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper] [ 66.777917] process_one_work+0x86b/0x1510 [ 66.777919] work_thread+0x5c0/0xfa0 [ 66.777922] kthread+0x3a2/0x840 [ 66.777925] ret_from_fork+0x40/0x90 [ 66.777927] ret_from_fork_asm+0x11/0x20 [ 66.777932] Liberado por la tarea 1713: [ 66.777935] kasan_save_stack+0x39/0x60 [ 66.777938] kasan_save_track+0x14/0x40 [ 66.777940] kasan_save_free_info+0x3b/0x60 [ 66.777944] __kasan_slab_free+0x52/0x70 [ 66.777946] kfree+0x13f/0x4b0 [ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu] [ 66.778179] drm_connector_free+0x7d/0xb0 [ 66.778184] drm_mode_object_put.part.0+0xee/0x160 [ 66.778188] drm_mode_object_put+0x37/0x50 [ 66.778191] drm_atomic_state_default_clear+0x220/0xd60 [ 66.778194] __drm_atomic_state_free+0x16e/0x2a0 [ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0 [ 66.778200] drm_ioctl_kernel+0x17a/0x310 [ 66.778203] drm_ioctl+0x584/0xd10 [ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu] [ 66.778375] __x64_sys_ioctl+0x139/0x1a0 [ 66.778378] x64_sys_call+0xee7/0xfb0 [ 66.778381] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: arregla la pérdida de inodo en btrfs_iget() [ERROR] Hay un informe de error que indica que un reproductor syzbot puede provocar el siguiente inodo ocupado en el momento del desmontaje: Información BTRFS (dispositivo loop1): último desmontaje del sistema de archivos 1680000e-3c1e-4c46-84b6-56bd3909af50 VFS: Inodos ocupados después del desmontaje de loop1 (btrfs) ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/super.c:650! Oops: código de operación no válido: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 48168 Comm: syz-executor No contaminado 6.15.0-rc2-00471-g119009db2674 #2 PREEMPT(full) Nombre del hardware: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 RIP: 0010:generic_shutdown_super+0x2e9/0x390 fs/super.c:650 Rastreo de llamadas: kill_anon_super+0x3a/0x60 fs/super.c:1237 btrfs_kill_super+0x3b/0x50 fs/btrfs/super.c:2099 deactivate_locked_super+0xbe/0x1a0 fs/super.c:473 deactivate_super fs/super.c:506 [inline] deactivate_super+0xe2/0x100 fs/super.c:502 cleanup_mnt+0x21f/0x440 fs/namespace.c:1435 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x269/0x290 kernel/entry/common.c:218 do_syscall_64+0xd4/0x250 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSA] Cuando btrfs_alloc_path() fallaba, btrfs_iget() regresaba directamente sin liberar el inodo ya asignado por btrfs_iget_locked(). Esto genera el inodo ocupado mencionado anteriormente y activa el error del kernel. [SOLUCIÓN] Corríjalo llamando a iget_failed() si btrfs_alloc_path() fallaba. Si encontramos un error en btrfs_read_locked_inode(), se llamará correctamente a iget_failed(), así que no hay de qué preocuparse. Aunque la limpieza de iget_failed() dentro de btrfs_read_locked_inode() supone una ruptura del esquema normal de gestión de errores, primero corregiremos el error obvio y lo adaptaremos a la versión anterior, y luego reescribiremos la gestión de errores.