Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: núcleo: eliminar WARN_ON() innecesario en implementar() Syzkaller recibió una advertencia [1] en una llamada a implementar() al intentar escribir un valor en un campo de tamaño más pequeño. tamaño en un informe de salida. Dado que implement() ya tiene un mensaje de advertencia impreso con la ayuda de hid_warn() y el valor en cuestión se recorta con: ... value &= m; ... WARN_ON puede considerarse superfluo. Elimínelo para suprimir futuros desencadenantes de syzkaller. [1] ADVERTENCIA: CPU: 0 PID: 5084 en drivers/hid/hid-core.c:1451 implementar drivers/hid/hid-core.c:1451 [en línea] ADVERTENCIA: CPU: 0 PID: 5084 en drivers/hid /hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 Módulos vinculados en: CPU: 0 PID: 5084 Comm: syz-executor424 No contaminado 6.9.0-rc7-syzkaller-00183 -gcf87f46fd34d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [en línea] RIP: 0010:hid_output_report+0x548/ 0x760 drivers/hid/hid-core.c:1863... Seguimiento de llamadas: __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [en línea] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid -core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0xfc/0x170 fs /ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f...

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cachefiles: fix slab-use-after-free in cachefiles_ondemand_daemon_read() Obtuvimos el siguiente problema en una prueba de ejecución aleatoria del comando de restauración: ======== ==================================================== ======== ERROR: KASAN: slab-use-after-free en cachefiles_ondemand_daemon_read+0xb41/0xb60 Lectura de tamaño 8 en la dirección ffff888122e84088 por tarea ondemand-04-dae/963 CPU: 13 PID: 963 Comm: ondemand -04-dae Not tainted 6.8.0-dirty #564 Seguimiento de llamadas: kasan_report+0x93/0xc0 cachefiles_ondemand_daemon_read+0xb41/0xb60 vfs_read+0x169/0xb50 ksys_read+0xf5/0x1e0 Asignado por tarea 116: kmem_cache_alloc+0x14 0/0x3a0 cachefiles_lookup_cookie+0x140/ 0xcd0 fscache_cookie_state_machine+0x43c/0x1230 [...] Liberado por la tarea 792: kmem_cache_free+0xfe/0x390 cachefiles_put_object+0x241/0x480 fscache_cookie_state_machine+0x5c8/0x1230 [...] =============== ==================================================== == El siguiente es el proceso que desencadena el problema: montar | daemon_thread1 | daemon_thread2 ------------------------------------------------- ----------- cachefiles_withdraw_cookie cachefiles_ondemand_clean_object(object) cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done) cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req- >object_id = solicitud->objeto ->ondemand->ondemand_id ------ restaurar ------ cachefiles_ondemand_restore xas_for_each(&xas, req, ULONG_MAX) xas_set_mark(&xas, CACHEFILES_REQ_NEW) cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req er, mensaje, n) xa_erase(&cache ->reqs, id) complete(&REQ_A->done) ------ close(fd) ------ cachefiles_ondemand_fd_release cachefiles_put_object cachefiles_put_object kmem_cache_free(cachefiles_object_jar, object) REQ_A->object->ondemand->ondemand_id // objeto UAF !!! Cuando vemos la solicitud dentro de xa_lock, req->object no debe haberse liberado aún, así que tome el recuento de referencia del objeto antes de xa_unlock para evitar el problema anterior.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cachefiles: fix slab-use-after-free in cachefiles_ondemand_get_fd() Obtuvimos el siguiente problema en una prueba de ejecución aleatoria del comando de restauración: ======== ==================================================== ======== ERROR: KASAN: slab-use-after-free en cachefiles_ondemand_daemon_read+0x609/0xab0 Escritura de tamaño 4 en la dirección ffff888109164a80 por tarea ondemand-04-dae/4962 CPU: 11 PID: 4962 Comm: ondemand -04-dae No contaminado 6.8.0-rc7-dirty #542 Seguimiento de llamadas: kasan_report+0x94/0xc0 cachefiles_ondemand_daemon_read+0x609/0xab0 vfs_read+0x169/0xb50 ksys_read+0xf5/0x1e0 Asignado por tarea 626: /0x4b0 archivos de caché_ondemand_send_req+ 0x24d/0x690 cachefiles_create_tmpfile+0x249/0xb30 cachefiles_create_file+0x6f/0x140 cachefiles_look_up_object+0x29c/0xa60 cachefiles_lookup_cookie+0x37d/0xca0 fscache_cookie_state_machine+0x43c/0x1230 [...] Liberado por tarea 626: kfree+0xf1/0x2c0 cachefiles_ondemand_send_req+0x568/0x690 cachefiles_create_tmpfile+ 0x249/0xb30 cachefiles_create_file+0x6f/0x140 cachefiles_look_up_object+0x29c/0xa60 cachefiles_lookup_cookie+0x37d/0xca0 fscache_cookie_state_machine+0x43c/0x1230 [...] ======================= ============================================= El siguiente es el proceso que desencadena el problema: montar | daemon_thread1 | daemon_thread2 ------------------------------------------------- ----------- cachefiles_ondemand_init_object cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done) cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req cachefiles_ondemand_get_fd usuario(_buffer, msg, n) proceso_open_req(REQ_A) ------ restaurar ------ cachefiles_ondemand_restore xas_for_each(&xas, req, ULONG_MAX) xas_set_mark(&xas, CACHEFILES_REQ_NEW); cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req write(devfd, ("copen %u,%llu", msg->msg_id, tamaño)); cachefiles_ondemand_copen xa_erase(&cache->reqs, id) complete(&REQ_A->done) kfree(REQ_A) cachefiles_ondemand_get_fd(REQ_A) fd = get_unused_fd_flags file = anon_inode_getfile fd_install(fd, file) load = (void *)REQ_A->msg.data; cargar->fd = fd; // carga UAF !!! Este problema se debe a la emisión de un comando de restauración cuando el daemon todavía está activo, lo que da como resultado que una solicitud se procese varias veces y, por lo tanto, se active una UAF. Entonces, para evitar este problema, agregue un recuento de referencia adicional a cachefiles_req, que se mantiene mientras se espera y se lee, y luego se libera cuando finaliza la espera y la lectura. Tenga en cuenta que, dado que solo hay un recuento de referencias para esperar, debemos evitar que la misma solicitud se complete varias veces, por lo que solo podemos completar la solicitud si se elimina con éxito del xarray.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: elimina solicitudes de xarray durante las solicitudes de vaciado Incluso con CACHEFILES_DEAD configurado, aún podemos leer las solicitudes, por lo que en la siguiente concurrencia la solicitud se puede usar después de que se haya liberado: mount | daemon_thread1 | daemon_thread2 ------------------------------------------------- --------- Cachefiles_ondemand_init_object Cachefiles_ondemand_send_req req_a = kzalloc (sizeof (*req) + data_len) Wait_for_completion (& req_a-> ded) gratis (req_a ) xa_lock(&cache->reqs); cachefiles_ondemand_select_req req->msg.opcode != CACHEFILES_OP_READ // ¡¡¡requiere use-after-free !!! xa_unlock(&cache->reqs); xa_destroy(&cache->reqs) Por lo tanto, elimine las solicitudes de cache->reqs cuando las vacíe para evitar acceder a las solicitudes liberadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Evite que test/set_bit() opere en memoria no asignada. Existe un posible acceso fuera de los límites cuando se usa test_bit() en una sola palabra. Las funciones test_bit() y set_bit() operan con valores largos y, al probar o configurar una sola palabra, pueden exceder el límite de la palabra. KASAN detecta este problema y produce un volcado: ERROR: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/ bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Escritura de tamaño 8 en la dirección ffff8881d26e3c60 mediante tarea kworker/u1536:2/2965 Para obtener el registro completo, consulte [1]. Realice la asignación al menos del tamaño de sizeof(unsigned long) para que set_bit() y test_bit() tengan suficiente espacio para operaciones de lectura/escritura sin sobrescribir la memoria no asignada. [1] Enlace: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jfs: xattr: corrige el desbordamiento del búfer para xattr no válido Cuando un tamaño de xattr no es el esperado, se imprime en el registro del kernel en formato hexadecimal como una forma de depuración. Pero cuando el tamaño de xattr es mayor que el tamaño esperado, imprimirlo puede provocar un acceso desde el final del búfer. Solucione todo esto restringiendo adecuadamente el tamaño del volcado hexadecimal de depuración en el registro del kernel.

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)