Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: arreglar el caso de use-after-free en tcpm_register_source_caps Podría haber un posible caso de use-after-free en tcpm_register_source_caps(). Esto podría suceder cuando: * se anuncian límites de fuente nuevos (por ejemplo, no válidos) * los límites de fuente existentes no están registrados * tcpm_register_source_caps() devuelve un error ya que usb_power_delivery_register_capabilities() falla Esto hace que port->partner_source_caps conserve los límites de fuente ahora liberados. Restablezca el valor de puerto->partner_source_caps a NULL después de cancelar el registro de los límites de origen existentes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: USB: clase: cdc-wdm: soluciona el bloqueo de la CPU causado por mensajes de registro excesivos. El syzbot fuzzer descubrió que la devolución de llamada de finalización de interrupción-URB en el controlador cdc-wdm estaba tardando demasiado y el reenvío inmediato por parte del controlador de las URB de interrupción con estado -EPROTO combinado con la emulación ficticia-hcd para provocar un bloqueo de la CPU: cdc_wdm 1-1:1.0: estado de urb distinto de cero recibido: -71 cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes perro guardián: ERROR: bloqueo suave - ¡CPU#0 bloqueada durante 26 segundos! [syz-executor782:6625] CPU#0 Utilización cada 4 segundos durante el bloqueo: #1: 98% sistema, 0% softirq, 3% hardirq, 0% inactivo #2: 98% sistema, 0% softirq, 3% hardirq, 0 % inactivo #3: 98% sistema, 0% softirq, 3% hardirq, 0% inactivo #4: 98% sistema, 0% softirq, 3% hardirq, 0% inactivo #5: 98% sistema, 1% softirq, 3 % hardirq, 0% inactivo Módulos vinculados en: irq event stamp: 73096 hardirqs habilitado por última vez en (73095): [] console_emit_next_record kernel/printk/printk.c:2935 [inline] hardirqs habilitado por última vez en (73095): [ ] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs deshabilitado por última vez en (73096): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [en línea] hardirqs último deshabilitado en (73096): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs habilitado por última vez en (73048): [] softirq_handle_end kernel/softirq.c:400 [en línea] softirqs habilitados por última vez en (73048): [] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs deshabilitados por última vez en (73043): [] __do_softirq+0x14/0x20 kernel/softirq. c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Contaminado: GW 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 Las pruebas mostraron que el problema no se produjo si se eliminaron los dos mensajes de error (las dos primeras líneas anteriores); aparentemente agregar material al registro del kernel lleva una cantidad de tiempo sorprendentemente grande. En cualquier caso, el mejor enfoque para prevenir estos bloqueos y evitar enviar spam al registro con miles de mensajes de error por segundo es limitar la velocidad de las dos llamadas dev_err(). Por eso los reemplazamos con dev_err_ratelimited().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: corrige posible ejecución en __fib6_drop_pcpu_from() syzbot encontró una ejecución en __fib6_drop_pcpu_from() [1] Si el compilador lee más de una vez (*ppcpu_rt), la segunda lectura podría leer NULL, si otra CPU borra el valor en rt6_get_pcpu_route(). Agregue un READ_ONCE() para evitar esta ejecución. Agregue también rcu_read_lock()/rcu_read_unlock() porque confiamos en la protección de RCU al eliminar la referencia a pcpu_rt. [1] Ups: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: trabajador/ u8:17 No contaminado 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 Cola de trabajo: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0 +0x10a/0x370 net/ipv6/ip6_fib.c:984 Código: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 X: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: ffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(00 00) GS:ffff8880b9200000(0000) knlGS:0000000000000000CS : 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001B32C26000 CR3: 000000005D56E000 CR4: 00000000003526F0 DR0: 00000000000000000000000000000000000000000000000000000000SET 0000000000FFFE0FF0 DR7: 000000000000000400 TRACE DE LLAMADA: __fib6_drop_pcpu_from net/ipv6/ip6_fib .c:966 [en línea] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [en línea] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [en línea] fib6_del+0xa70 /0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 /ip6_fib. c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [en línea] /0xa00 neto /ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c :93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [en línea] call_netdevice_notifiers net/core/dev.c:2044 [en línea] dev_close_many+0x333/0x6a0 net/core /dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [en línea] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x 128 /0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 Process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Process_scheduled_works kernel/workqueue.c:3312 [en línea] work_thread+ 0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64 .S:244

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5: detener siempre el temporizador de estado durante la eliminación del controlador. Actualmente, si teardown_hca no se ejecuta durante la eliminación del controlador, mlx5 no detiene el temporizador de estado. Posteriormente, mlx5 continúa con el desmontaje del controlador. Esto puede provocar un error de UAF, lo que resulta en un error de página Ups[1], ya que el temporizador de estado se invoca después de que se liberaron los recursos. Por lo tanto, detenga el monitor de salud incluso si falla Teardown_hca. [1] mlx5_core 0000:18:00.0: E-Switch: Descargar vfs: modo(LEGACY), nvfs(0), necvfs(0), vports activos(0) mlx5_core 0000:18:00.0: E-Switch: Deshabilitar: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5_core 0000:18:00.0: E-Switch: Desactivar: mode(LEGACY), nvfs(0), necvfs(0), active vports (0) mlx5_core 0000:18:00.0: E-Switch: limpieza mlx5_core 0000:18:00.0: wait_func:1155:(pid 1967079): TEARDOWN_HCA(0x103) tiempo de espera. Provocará una fuga de un recurso de comando mlx5_core 0000:18:00.0: mlx5_function_close:1288:(pid 1967079): falló el desmontaje_hca, omitió la limpieza ERROR: no se puede manejar el error de página para la dirección: ffffa26487064230 PGD 100c00067 P4D 100c00067 PUD 67 PMD 105ed7067 PTE 0 Vaya: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comunicaciones: intercambiador/0 Contaminado: G OE ------- --- 6.7.0-68.fc38.x86_64 #1 Nombre de hardware: Intel Corporación S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0013.121520200651 15/12/2020 RIP: 0010:ioread32be+0x34/0x60 RSP: 0018:ffffa26480003e58 EFLAGS: 2 RAX: ffffa26487064200 RBX: ffff9042d08161a0 RCX: ffff904c108222c0 RDX: 000000010bbf1b80 RSI: ffffffffc055ddb0 RDI: ffffa26487064230 RBP: ffff9042d08161a0 R08: 0000000000000022 R09: ffff904c108222e8 R10: 00000000000000004 R11: 0000000000000441 R12: ffffffc055ddb0 R13: ffffa26487064200 R14: ffffa26480003f00 R15: ffff904c108222c0 FS: 0000000000000000(0000) GS:ffff904c10800000(0000) 0000000000CS: 0010DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa26487064230 CR3: 00000002c4420006 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000 000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: ? __morir+0x23/0x70 ? page_fault_oops+0x171/0x4e0? exc_page_fault+0x175/0x180? asm_exc_page_fault+0x26/0x30? __pfx_poll_health+0x10/0x10 [mlx5_core] ? __pfx_poll_health+0x10/0x10 [mlx5_core] ? ioread32be+0x34/0x60 mlx5_health_check_fatal_sensors+0x20/0x100 [mlx5_core] ? __pfx_poll_health+0x10/0x10 [mlx5_core] poll_health+0x42/0x230 [mlx5_core] ? __next_timer_interrupt+0xbc/0x110? __pfx_poll_health+0x10/0x10 [mlx5_core] call_timer_fn+0x21/0x130? __pfx_poll_health+0x10/0x10 [mlx5_core] __run_timers+0x222/0x2c0 run_timer_softirq+0x1d/0x40 __do_softirq+0xc9/0x2c8 __irq_exit_rcu+0xa6/0xc0 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:cpuidle_enter_state +0xcc/0x440 ? cpuidle_enter_state+0xbd/0x440 cpuidle_enter+0x2d/0x40 do_idle+0x20d/0x270 cpu_startup_entry+0x2a/0x30 rest_init+0xd0/0xd0 arch_call_rest_init+0xe/0x30 start_kernel+0x709/0xa90 x86_64_start _reservations+0x18/0x30 x86_64_start_kernel+0x96/0xa0 second_startup_64_no_verify+0x18f/0x19b ---[ final de seguimiento 0000000000000000 ]---

Securepoint UTM anterior a 12.6.5 maneja mal los códigos OTP.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mst: corrige la desreferencia del puntero NULL en drm_dp_add_payload_part2 [Por qué] Commit: - commit 5aa1dfcdf0a4 ("drm/mst: refactorizar el flujo para la asignación/eliminación de carga") sobrescribe accidentalmente el commit - commit 54d217406afe ("drm: use mgr->dev en drm_dbg_kms en drm_dp_add_payload_part2") que causa regresión. [Cómo] Recupere la corrección NULL original y elimine el parámetro de entrada innecesario 'estado' para drm_dp_add_payload_part2(). (cereza escogida del commit 4545614c1d8da603e57b60dd66224d81b6ffc305)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: core: sincronizar Actually_probe() y dev_uevent() Sincronizar el uso dev->driver en Actually_probe() y dev_uevent(). Estos pueden ejecutarse en diferentes subprocesos, lo que puede resultar en la siguiente condición de ejecución para dev->desinicialización del controlador: Subproceso n.° 1: ========== reality_probe() { ... probe_failed: ... device_unbind_cleanup( dev) { ... dev->controlador = NULL; // <= La sonda fallida establece dev->driver en NULL ... } ... } Hilo #2: ========== dev_uevent() { ... if (dev->driver) / / Si dev->driver recibe un valor NULL desde reality_probe() de ahora en adelante, // después de la verificación anterior, el sistema falla add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... }realmente_probe() ya tiene el bloqueo. Entonces no es necesario hacer nada allí. A menudo también se llama a dev_uevent() con el bloqueo mantenido. Pero no siempre. Lo que implica que no podemos agregar ningún bloqueo en el propio dev_uevent(). Así que arregle esta ejecución agregando el candado al camino no protegido. Esta es la ruta donde se observa la ejecución anterior: dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Agregar bloqueo aquí dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/ 0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Casos similares son reportados por syzkaller en https://syzkaller.appspot.com/bug?extid =ffa8143439596313a85a Pero estos se refieren a la *inicialización* de dev->driver dev->driver = drv; Como esto cambia dev->driver a no NULL, estos informes pueden considerarse falsos positivos (aunque esté commit también debería "solucionarlos"). El mismo problema se informó y se intentó solucionar en 2015 en https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/ ya.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_inner: valida meta y payload obligatorias. Comprueba los atributos de enlace de red obligatorios en el payload y la metaexpresión cuando se utilizan incrustados desde la expresión interna; de lo contrario, es posible desreferenciar el puntero NULL desde el espacio de usuario.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ima: corrige el use-after-free en dentry dname.name ->d_name.name puede cambiar al cambiar el nombre y el valor anterior se puede liberar; existen condiciones suficientes para estabilizarlo (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusivo en el inodo del padre, rename_lock), pero ninguna de ellas se cumple en ninguno de los sitios. En su lugar, tome una instantánea estable del nombre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs:zoned: corrige el use-after-free debido a la ejecución con el reemplazo de desarrollo. Mientras cargamos la información de una zona durante la creación de un grupo de bloques, podemos ejecutar una operación de reemplazo de dispositivo y luego activar un use-after-free en el dispositivo que acaba de ser reemplazado (dispositivo fuente de la operación de reemplazo). Esto sucede porque en btrfs_load_zone_info() extraemos un dispositivo del mapa de fragmentos en una variable local y luego usamos el dispositivo mientras no está bajo la protección del dispositivo y reemplazamos rwsem. Entonces, si se produce una operación de reemplazo de dispositivo cuando extraemos el dispositivo y ese dispositivo es la fuente de la operación de reemplazo, activaremos un use-after-free si antes de terminar de usar el dispositivo la operación de reemplazo finaliza y libera el dispositivo. Solucione este problema ampliando la sección crítica bajo la protección del dispositivo y reemplace rwsem para que todos los usos del dispositivo se realicen dentro de la sección crítica.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: greybus: corrigió el error de use-after-free en gb_interface_release debido a la condición de ejecución. En gb_interface_create, &intf->mode_switch_completion está vinculado con gb_interface_mode_switch_work. Luego lo iniciará gb_interface_request_mode_switch. Aquí está el código relevante. if (!queue_work(system_long_wq, &intf->mode_switch_work)) { ... } Si llamamos a gb_interface_release para realizar la limpieza, es posible que haya un trabajo sin terminar. Esta función llamará a kfree para liberar el objeto "intf". Sin embargo, si gb_interface_mode_switch_work está programado para ejecutarse después de kfree, puede causar un error de use-after-free ya que gb_interface_mode_switch_work usará el objeto "intf". El posible flujo de ejecución que puede provocar el problema es el siguiente: CPU0 CPU1 | gb_interface_create | gb_interface_request_mode_switch gb_interface_release | kfree(intf) (gratis) | | gb_interface_mode_switch_work | mutex_lock(&intf->mutex) (uso) Solucionarlo cancelando el trabajo antes de kfree.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/shmem-helper: corrige BUG_ON() en mmap(PROT_WRITE, MAP_PRIVATE) La falta de verificación para el mapeo de copia en escritura (COW) en drm_gem_shmem_mmap permite a los usuarios llamar a mmap con Los indicadores PROT_WRITE y MAP_PRIVATE causan un pánico en el kernel debido a BUG_ON en vmf_insert_pfn_prot: BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); Devuelva -EINVAL temprano si se detecta el mapeo COW. Este error afecta a todos los controladores drm que utilizan ayudantes shmem predeterminados. Se puede reproducir con este sencillo ejemplo: void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset); ptr[0] = 0;