Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: accel/ivpu: Se corrige el orden de bloqueo en ivpu_job_submit. Se corrige el bloqueo en el envío de trabajos y la gestión de abortos. Cuando un hilo cancela trabajos en ejecución debido a un fallo, primero bloquea el bloqueo global que protege submit_jobs (#1). Tras la destrucción del último trabajo, libera el contexto relacionado y bloquea file_priv (#2). Mientras tanto, en el hilo de envío de trabajos, primero se obtiene el bloqueo file_priv (#2) y, a continuación, el bloqueo submit_jobs (#1) al añadir un trabajo a la lista de trabajos enviados. CPU0 CPU1 ---- ---- (por ejemplo, debido a un fallo) (los envíos de trabajos siguen llegando) lock(&vdev->submitted_jobs_lock) #1 ivpu_jobs_abort_all() job_destroy() lock(&file_priv->lock) #2 lock(&vdev->submitted_jobs_lock) #1 file_priv_release() lock(&vdev->context_list_lock) lock(&file_priv->lock) #2 Este orden de bloqueo provoca un interbloqueo. Para solucionar este problema, cambie el orden de bloqueo en ivpu_job_submit().

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: 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: ublk: se corrige la ejecución entre io_uring_cmd_complete_in_task y ublk_cancel_cmd. ublk_cancel_cmd() llama a io_uring_cmd_done() para completar uring_cmd, pero es posible que hayamos programado el trabajo de la tarea mediante io_uring_cmd_complete_in_task() para el envío de la solicitud, lo que puede provocar un fallo del kernel. Para solucionarlo, no intente cancelar el comando si se inicia la solicitud de bloqueo de ublk.

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: 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: 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: 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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scmi: Equilibrar el recuento de referencias de dispositivos al destruir dispositivos. El uso de device_find_child() para buscar el dispositivo SCMI adecuado para destruir provoca un desequilibrio en el recuento de referencias de dispositivos, ya que device_find_child() llama a un método get_device() implícito: esto, a su vez, inhibe la llamada a los métodos de liberación proporcionados tras la destrucción de dispositivos. Como consecuencia, una de las estructuras que no se libera correctamente tras la destrucción es la estructura interna device_private dev->p, rellenada por el núcleo del subsistema de controladores. KMemleak detecta esta situación, ya que la carga/descarga de algún controlador SCMI provoca que los dispositivos relacionados se creen/destruyan sin llamar a ningún método device_release. objeto sin referencia 0xffff00000f583800 (tamaño 512): comm "insmod", pid 227, jiffies 4294912190 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... seguimiento inverso (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158 $ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0 device_add+0x954/0x12d0: kmalloc_noprof en include/linux/slab.h:901 (en línea por) kzalloc_noprof en include/linux/slab.h:1037 (en línea por) device_private_init en drivers/base/core.c:3510 (en línea por) device_add en drivers/base/core.c:3561 Equilibre el recuento de dispositivos emitiendo un put_device() en los dispositivos encontrados a través de device_find_child().

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.