Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Arreglar UAF a través de la falta de coincidencia de los sabores de RCU de bpf_prog/attachment Los uprobes siempre usan bpf_prog_run_array_uprobe() bajo la protección de tareas-trace-RCU. Pero es posible adjuntar un programa BPF no durmiente a un uprobe, y los programas BPF no durmientes se liberan a través de RCU normal (ver __bpf_prog_put_noref()). Esto lleva a UAF de bpf_prog porque un período de gracia de RCU normal no implica un período de gracia de tareas-trace-RCU. Arréglelo esperando explícitamente un período de gracia de tareas-trace-RCU después de eliminar la conexión de un bpf_prog a un perf_event.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Desreferenciar valor de retorno nulo En la función pqm_uninit hay una asignación de llamada de "pdd = kfd_get_process_device_data" que podría ser nulo, y este valor fue posteriormente desreferenciado sin verificación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915: Se corrige la desreferencia de puntero NULL en capture_engine Cuando la estructura intel_context contiene NULL, genera un error de desreferencia de puntero NULL en drm_info(). (seleccionado de el commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Arreglar el puntero NULL de qi_batch con el dominio principal anidado El qi_batch se asigna al asignar la etiqueta de caché para un dominio. Mientras que para el dominio principal anidado, se omite. Por lo tanto, al intentar asignar páginas al principal anidado, se produjo una desreferencia NULL. Además, existe una posible fuga de memoria ya que no hay un bloqueo alrededor de la asignación de dominio->qi_batch. Para resolverlo, agregue un ayudante para la asignación de qi_batch y llámelo tanto en __cache_tag_assign_domain() como en __cache_tag_assign_parent_domain(). ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000200 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 8104795067 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 223 UID: 0 PID: 4357 Comm: qemu-system-x86 No contaminado 6.13.0-rc1-00028-g4b50c3c3b998-dirty #2632 Seguimiento de llamadas: ? __die+0x24/0x70 ? page_fault_oops+0x80/0x150 ? do_user_addr_fault+0x63/0x7b0 ? exc_page_fault+0x7c/0x220 ? asm_exc_page_fault+0x26/0x30 ? rango_de_vaciado_de_etiqueta_de_caché_np+0x13c/0x260 intel_iommu_iotlb_sync_map+0x1a/0x30 iommu_map+0x61/0xf0 lote_a_dominio+0x188/0x250 iopt_area_fill_domains+0x125/0x320 ? iopt_map_pages+0x63/0x100 iopt_map_common.isra.0+0xa7/0x190 iopt_map_user_pages+0x6a/0x80 iommufd_ioas_map+0xcd/0x1d0 iommufd_fops_ioctl+0x118/0x1c0 __x64_sys_ioctl+0x93/0xc0 hacer_syscall_64+0x71/0x140 entrada_SYSCALL_64_después_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: eliminar etiquetas de caché antes de deshabilitar ATS La implementación actual elimina las etiquetas de caché después de deshabilitar ATS, lo que genera posibles fugas de memoria y fallas del kernel. Específicamente, las etiquetas de caché de tipo CACHE_TAG_DEVTLB pueden permanecer en la lista incluso después de que se libere el dominio, lo que provoca una condición de use-after-free. Este problema realmente aparece cuando múltiples VF de diferentes PF pasan a un solo proceso de espacio de usuario a través de vfio-pci. En tales casos, el núcleo puede bloquearse con mensajes como: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000014 PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 74 UID: 0 PID: 3183 Comm: testCli No contaminado 6.11.9 #2 RIP: 0010:cache_tag_flush_range+0x9b/0x250 Rastreo de llamadas: ? __die+0x1f/0x60 ? page_fault_oops+0x163/0x590 ? exc_page_fault+0x72/0x190 ? asm_exc_page_fault+0x22/0x30 ? rango_de_desinfección_de_etiquetas_de_caché+0x9b/0x250 ? cache_tag_flush_range+0x5d/0x250 intel_iommu_tlb_sync+0x29/0x40 intel_iommu_unmap_pages+0xfe/0x160 __iommu_unmap+0xd8/0x1a0 vfio_unmap_unpin+0x182/0x340 [vfio_iommu_type1] vfio_remove_dma+0x2a/0xb0 [vfio_iommu_type1] vfio_iommu_type1_ioctl+0xafa/0x18e0 [vfio_iommu_type1] Mueva cache_tag_unassign_domain() antes de iommu_disable_pci_caps() para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: graniterapids: Corregir fallo del controlador vGPIO Mover la configuración irq_chip.name de la función probe() a la inicialización de la estructura "irq_chip" para corregir el fallo del controlador vGPIO durante el arranque. El fallo fue causado por una modificación no autorizada del campo irq_chip.name donde la estructura irq_chip se inicializó como const. Este comportamiento es una consecuencia de la implementación subóptima de gpio_irq_chip_set_chip(), que debería cambiarse para evitar descartar el calificador const. Registro de fallos: ERROR: no se puede gestionar el error de página para la dirección: ffffffffc0ba81c0 /#PF: acceso de escritura del supervisor en modo kernel /#PF: error_code(0x0003) - violación de permisos CPU: 33 UID: 0 PID: 1075 Comm: systemd-udevd No contaminado 6.12.0-rc6-00077-g2e1b3cc9d7f7 #1 Nombre del hardware: Intel Corporation Kaseyville RP/Kaseyville RP, BIOS KVLDCRB1.PGS.0026.D73.2410081258 10/08/2024 RIP: 0010:gnr_gpio_probe+0x171/0x220 [gpio_graniterapids]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: acpi: nfit: vmalloc-out-of-bounds Lectura en acpi_nfit_ctl Se soluciona un problema detectado por syzbot con KASAN: ERROR: KASAN: vmalloc-out-of-bounds en cmd_to_func drivers/acpi/nfit/ core.c:416 [en línea] ERROR: KASAN: vmalloc-out-of-bounds en acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459 El problema ocurre en cmd_to_func cuando se accede a la matriz call_pkg->nd_reserved2 sin verificar que call_pkg apunte a un búfer que tenga el tamaño adecuado como una estructura nd_cmd_pkg. Esto puede provocar un acceso fuera de los límites y un comportamiento indefinido si el búfer no tiene suficiente espacio. Para solucionar este problema, se agregó una verificación en acpi_nfit_ctl() para garantizar que buf no sea NULL y que buf_len sea menor que sizeof(*call_pkg) antes de acceder a él. Esto garantiza un acceso seguro a los miembros de call_pkg, incluida la matriz nd_reserved2.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: corrección del error NL80211_ATTR_MLO_LINK_ID en uno Dado que la validación del rango del atributo netlink proporciona una verificación inclusiva, el *máximo* del atributo NL80211_ATTR_MLO_LINK_ID debe ser IEEE80211_MLD_MAX_NUM_LINKS - 1, lo que de lo contrario provocaría un error de uno. Una pila de fallos para demostración: ==================================================================== ERROR: KASAN: acceso a memoria salvaje en ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939 Lectura de tamaño 6 en la dirección 001102080000000c por la tarea fuzzer.386/9508 CPU: 1 PID: 9508 Comm: syz.1.386 No contaminado 6.1.70 #2 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_report+0xe0/0x750 mm/kasan/report.c:398 kasan_report+0x139/0x170 mm/kasan/report.c:495 kasan_check_range+0x287/0x290 mm/kasan/generic.c:189 memcpy+0x25/0x60 mm/kasan/shadow.c:65 ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939 rdev_tx_control_port net/wireless/rdev-ops.h:761 [en línea] nl80211_tx_control_port+0x7b3/0xc40 net/wireless/nl80211.c:15453 genl_family_rcv_msg_doit+0x22e/0x320 net/netlink/genetlink.c:756 genl_family_rcv_msg net/netlink/genetlink.c:833 [en línea] genl_rcv_msg+0x539/0x740 net/netlink/genetlink.c:850 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 genl_rcv+0x24/0x40 net/netlink/genetlink.c:861 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [en línea] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [en línea] __sock_sendmsg net/socket.c:728 [en línea] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [en línea] __do_sys_sendmsg net/socket.c:2591 [en línea] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd Actualice la política para garantizar una validación correcta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Se corrige la competencia entre el reemplazo de elementos y close(). El reemplazo de elementos (con un socket diferente del almacenado) puede competir con el enlace de close() del socket, haciendo estallar y desvinculando el enlace. __sock_map_delete() anula la referencia incondicional del elemento (incorrecto): // establece map[0] = s0 map_update_elem(map, 0, s0) // elimina fd de s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // reemplaza map[0] con s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) si (conteo_de_referencias_y_pruebas(&psock)) sk_psock_drop(sk, psock) desbloqueo_spin(&stab->bloqueo) desbloqueo_sock(sk) __sock_map_delete bloqueo_spin(&stab->bloqueo) sk = *psk // s1 reemplazó a s0; sk == s1 si (!sk_prueba || sk_prueba == sk) // sk_prueba (s0) != sk (s1); sin rama sk = xchg(psk, NULL) si (sk) sock_map_unref(sk, psk) // desreferenciar s1; sks[idx] dejará colgado psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk) Luego close(map) pone en cola bpf_map_free_deferred, que finalmente llama a sock_map_free(). Esto da como resultado algunas advertencias refcount_t junto con un splat KASAN [1]. Corrija __sock_map_delete(), no permita sock_map_unref() en elementos que pueden haber sido reemplazados. [1]: ERROR: KASAN: slab-use-after-free en sock_map_free+0x10e/0x330 Escritura de tamaño 4 en la dirección ffff88811f5b9100 por la tarea kworker/u64:12/1063 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 No contaminado 6.12.0+ #125 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Cola de trabajo: events_unbound bpf_map_free_deferred Rastreo de llamadas: dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 Asignado por la tarea 1202: pila de guardado kasan+0x1e/0x40 seguimiento de guardado kasan+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 La librería ---truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf,perf: Se corrige el acceso no válido a prog_array en perf_event_detach_bpf_prog Syzbot informó [1] un fallo que ocurre en el siguiente escenario de seguimiento: - crear un evento perf de tracepoint con attr.inherit=1, adjuntarlo al proceso y establecerle el programa bpf - el proceso adjunto se bifurca -> chid crea un evento heredado el nuevo evento secundario comparte el programa bpf del padre y tp_event (de ahí prog_array) que es global para tracepoint - salir tanto del proceso como de su hijo -> liberar ambos eventos - la primera llamada perf_event_detach_bpf_prog liberará tp_event->prog_array y la segunda perf_event_detach_bpf_prog se bloqueará, porque tp_event->prog_array es NULL La corrección asegura que las comprobaciones perf_event_detach_bpf_prog prog_array es válido antes de intentar eliminar el programa bpf de él. [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: u_serial: soluciona el problema por el cual gs_start_io se bloqueaba debido al acceso a un puntero nulo. Teniendo en cuenta que en algunos casos extremos, cuando varios subprocesos acceden al controlador u_serial, el subproceso A ejecuta la operación de apertura y llama a gs_open, el subproceso B ejecuta la operación de desconexión y llama a la función gserial_disconnect, el puntero port->port_usb se establecerá en NULL. P. ej. Hilo A Hilo B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Bloqueo Esto hace que el hilo A acceda a un puntero nulo (port->port_usb es nulo) al llamar a la función gs_free_requests, lo que provoca un bloqueo. Si port_usb es NULL, se omitirá la solicitud de liberación, ya que la realizará gserial_disconnect. Por lo tanto, agregue una verificación de puntero nulo a gs_start_io antes de intentar acceder al valor del puntero port->port_usb. Rastreo de llamadas: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invocar_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/reg_sr: Eliminar el grupo de registros Esa implementación del grupo no funciona realmente: si el krealloc mueve la memoria y devuelve otra dirección, las entradas en el xarray dejan de ser válidas, lo que lleva a un use-after-free más adelante: ERROR: KASAN: slab-use-after-free en xe_reg_sr_apply_mmio+0x570/0x760 [xe] Lectura de tamaño 4 en la dirección ffff8881244b2590 por la tarea modprobe/2753 Asignado por la tarea 2753: kasan_save_stack+0x39/0x70 kasan_save_track+0x14/0x40 kasan_save_alloc_info+0x37/0x60 __kasan_kmalloc+0xc3/0xd0 __kmalloc_node_track_caller_noprof+0x200/0x6d0 krealloc_noprof+0x229/0x380 Simplifique el código para corregir el error. Es posible que se agregue una mejor estrategia de agrupamiento más adelante si es necesario. (seleccionada de el commit e5283bd4dfecbd3335f43b62a68e24dae23f59e4)