Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: corrige la advertencia de falso positivo en extack durante los volcados Commit bajo corrige el informe extendido de extack a los volcados. Funciona en condiciones normales, porque los errores de extack generalmente se informan durante ->start() o el primer ->dump(), es bastante raro que el volcado comience bien pero falle más tarde. Sin embargo, si el volcado falla más tarde, el skb de entrada ya tendrá el mensaje de inicio extraído, por lo que la verificación de si el atributo incorrecto cae dentro de skb->data fallará. Cambie la verificación para usar nlh, que siempre es válido. syzbot encontró una forma de abordar ese escenario llenando la cola de recepción. En este caso, iniciamos un volcado pero no llamamos a ->dump() hasta que haya espacio de lectura para un skb. ADVERTENCIA: CPU: 1 PID: 5845 en net/netlink/af_netlink.c:2210 netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209 RIP: 0010:netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209 Seguimiento de llamadas: netlink_dump_done+0x513/0x970 net/netlink/af_netlink.c:2250 netlink_dump+0x91f/0xe10 net/netlink/af_netlink.c:2351 netlink_recvmsg+0x6bb/0x11d0 net/netlink/af_netlink.c:1983 sock_recvmsg_nosec net/socket.c:1051 [en línea] sock_recvmsg+0x22f/0x280 net/socket.c:1073 __sys_recvfrom+0x246/0x3d0 net/socket.c:2267 __do_sys_recvfrom net/socket.c:2285 [en línea] __se_sys_recvfrom net/socket.c:2281 [en línea] __x64_sys_recvfrom+0xde/0x100 net/socket.c:2281 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entrada_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff37dd17a79

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: release svc_expkey/svc_export with rcu_work La última referencia para `cache_head` se puede reducir a cero en `c_show` y `e_show` (usando `rcu_read_lock` y `rcu_read_unlock`). En consecuencia, se invocarán `svc_export_put` y `expkey_put`, lo que provocará dos problemas: 1. `svc_export_put` liberará directamente ex_uuid. Sin embargo, `e_show`/`c_show` accederá a `ex_uuid` después de `cache_put`, lo que puede desencadenar un problema de use-after-free, que se muestra a continuación. ====================================================================== ERROR: KASAN: slab-use-after-free en svc_export_show+0x362/0x430 [nfsd] Lectura de tamaño 1 en la dirección ff11000010fdc120 por la tarea cat/870 CPU: 1 UID: 0 PID: 870 Comm: cat No contaminado 6.12.0-rc3+ #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Seguimiento de llamadas: dump_stack_lvl+0x53/0x70 imprimir_dirección_descripción.constprop.0+0x2c/0x3a0 imprimir_informe+0xb9/0x280 kasan_informe+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 hacer_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Asignado por la tarea 830: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] 2. No podemos dormir mientras usamos `rcu_read_lock`/`rcu_read_unlock`. Sin embargo, `svc_export_put`/`expkey_put` llamará a path_put, que posteriormente activa una operación de dormir debido al siguiente `dput`. ============================== ADVERTENCIA: uso sospechoso de RCU 5.10.0-dirty #141 No contaminado ----------------------------- ... Seguimiento de llamadas: dump_stack+0x9a/0xd0 ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Solucione estos problemas utilizando `rcu_work` para ayudar a liberar `svc_expkey`/`svc_export`. Este enfoque permite que un contexto asincrónico invoque `path_put` y también facilita la liberación de `uuid/exp/key` después de un período de gracia de RCU.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corregir ejecución en f2fs_stop_gc_thread concurrente En mi caso de prueba, las llamadas concurrentes a f2fs shutdown informan el siguiente seguimiento de pila: Oops: error de protección general, probablemente para dirección no canónica 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo No contaminado 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85 Seguimiento de llamada: ? show_regs+0x8b/0xa0 ? __die_body+0x26/0xa0 ? die_addr+0x54/0x90 ? exc_proteccion_general+0x24b/0x5c0 ? asm_exc_proteccion_general+0x26/0x30 ? kthread_stop+0x46/0x390 f2fs_stop_gc_thread+0x6c/0x110 f2fs_do_shutdown+0x309/0x3a0 f2fs_ioc_shutdown+0x150/0x1c0 __f2fs_ioctl+0xffd/0x2ac0 f2fs_ioctl+0x76/0xe0 vfs_ioctl+0x23/0x60 __x64_sys_ioctl+0xce/0xf0 x64_sys_call+0x2b1b/0x4540 do_syscall_64+0xa7/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e La causa raíz es una condición de ejecución en f2fs_stop_gc_thread() llamado desde diferentes rutas de apagado de f2fs: [CPU0] [CPU1] ---------------------- ----------------------- f2fs_stop_gc_thread f2fs_stop_gc_thread gc_th = sbi->gc_thread gc_th = sbi->gc_thread kfree(gc_th) sbi->gc_thread = NULL < gc_th != NULL > kthread_stop(gc_th->f2fs_gc_task) //UAF el commit c7f114d864ac ("f2fs: corrección para evitar el use-after-free en f2fs_stop_gc_thread()") intentó corregir este problema al usar un semáforo de lectura para evitar ejecuciones entre los subprocesos de apagado y remontaje, pero no logra evitar todas las condiciones de ejecuciones. Arréglelo convirtiendo en bloqueo de escritura s_umount en f2fs_do_shutdown().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtiofs: usar páginas en lugar de puntero para E/S directa del kernel Al intentar insertar un módulo de kernel de 10 MB guardado en un virtio-fs con la caché deshabilitada, se informó la siguiente advertencia: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 404 en mm/page_alloc.c:4551 ...... Módulos vinculados: CPU: 1 PID: 404 Comm: insmod No contaminado 6.9.0-rc5+ #123 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Rastreo de llamadas: ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... ---[ end trace 000000000000000 ]--- La advertencia se activa de la siguiente manera: 1) syscall finit_module() gestiona la inserción del módulo e invoca kernel_read_file() para leer primero el contenido del módulo. 2) kernel_read_file() asigna un búfer de 10 MB mediante vmalloc() y lo pasa a kernel_read(). kernel_read() construye un iter kvec utilizando iov_iter_kvec() y lo pasa a fuse_file_read_iter(). 3) virtio-fs desactiva la caché, por lo que fuse_file_read_iter() invoca fuse_direct_io(). Por ahora, el tamaño máximo de lectura para el iter kvec solo está limitado por fc->max_read. Para virtio-fs, max_read es UINT_MAX, por lo que fuse_direct_io() no divide el búfer de 10 MB. Guarda la dirección y el tamaño del búfer de 10 MB en out_args[0] de una solicitud de fuse y pasa la solicitud de fuse a virtio_fs_wake_pending_and_unlock(). 4) virtio_fs_wake_pending_and_unlock() utiliza virtio_fs_enqueue_req() para poner en cola la solicitud. Debido a que los virtiofs necesitan una dirección que pueda ser DMA, virtio_fs_enqueue_req() usa kmalloc() para asignar un buffer de rebote para todos los argumentos de fusión, copia estos argumentos en el buffer de rebote y pasa la dirección física del buffer de rebote a virtiofsd. La longitud total de estos argumentos de fusión para la solicitud de fusión pasada es de aproximadamente 10 MB, por lo que copy_args_to_argbuf() invoca kmalloc() con un parámetro de tamaño de 10 MB y activa la advertencia en __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL; 5) virtio_fs_enqueue_req() volverá a intentar la asignación de memoria en un kworker, pero no ayudará, porque kmalloc() siempre devolverá NULL debido al tamaño anormal y finit_module() se colgará para siempre. Una solución factible es limitar el valor de max_read para virtio-fs, por lo que la longitud pasada a kmalloc() será limitada. Sin embargo, afectará el tamaño máximo de lectura para la lectura normal. Y para la escritura de virtio-fs iniciada desde el kernel, tiene el mismo problema pero ahora no hay forma de limitar fc->max_write en el kernel. Entonces, en lugar de limitar los valores de max_read y max_write en el kernel, se introduce use_pages_for_kvec_io en fuse_conn y se establece como verdadero en virtiofs. Cuando use_pages_for_kvec_io está habilitado, fuse usará páginas en lugar de punteros para pasar los datos de KVEC_IO. Después de cambiar a páginas para los datos de KVEC_IO, estas páginas se usarán para DMA a través de virtio-fs. Si estas páginas están respaldadas por vmalloc(), {flush|invalidate}_kernel_vmap_range() son necesarias para vaciar o invalidar la caché antes de la operación de DMA. Por lo tanto, agregue dos nuevos campos en fuse_args_pages para registrar la dirección base del área vmalloc y la condición que indica si se necesita invalidación. --truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: usb: lan78xx: Se soluciona el problema de doble liberación con la asignación de búfer de interrupción En lan78xx_probe(), el búfer `buf` se liberaba dos veces: una vez implícitamente a través de `usb_free_urb(dev->urb_intr)` con el indicador `URB_FREE_BUFFER` y otra vez explícitamente por `kfree(buf)`. Esto causaba un problema de doble liberación. Para resolver esto, reordenamos las llamadas `kmalloc()` y `usb_alloc_urb()` para simplificar la secuencia de inicialización y eliminamos el `kfree(buf)` redundante. Ahora, `buf` se asigna después de `usb_alloc_urb()`, lo que garantiza que `usb_fill_int_urb()` lo administre correctamente y que `usb_free_urb()` lo libere como estaba previsto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/pci: Ocultar correctamente la primera capacidad extendida PCIe de la lista Hay casos en los que una capacidad extendida PCIe debería estar oculta al usuario. Por ejemplo, una capacidad desconocida (es decir, una capacidad con un ID mayor que PCI_EXT_CAP_ID_MAX) o una capacidad que se elige intencionalmente para que esté oculta al usuario. Para ocultar una capacidad, se virtualiza y modifica el campo "Next Capability Offset" de la capacidad anterior para que apunte a la capacidad después de la que debería estar oculta. El caso especial en el que la primera capacidad de la lista debería estar oculta se gestiona de forma diferente porque no hay ninguna capacidad anterior que pueda modificarse. En este caso, el ID y la versión de la capacidad se ponen a cero mientras que el siguiente puntero queda intacto. Esto oculta la capacidad y deja un ancla para el resto de la lista de capacidades. Sin embargo, hoy en día, ocultar la primera capacidad en la lista no se hace correctamente si la capacidad es desconocida, ya que struct vfio_pci_core_device->pci_config_map se establece en el ID de capacidad durante la inicialización, pero el ID de capacidad no se verifica correctamente más tarde cuando se usa en vfio_config_do_rw(). Esto lleva a la siguiente advertencia [1] y a un acceso fuera de los límites a la matriz ecap_perms. Arréglelo verificando cap_id en vfio_config_do_rw(), y si es mayor que PCI_EXT_CAP_ID_MAX, use un struct perm_bits alternativo para acceso directo de solo lectura en lugar de la matriz ecap_perms. Tenga en cuenta que esto es seguro ya que el anterior es el único caso en el que cap_id puede superar a PCI_EXT_CAP_ID_MAX (excepto para las capacidades especiales, que ya se verificaron antes). [1] ADVERTENCIA: CPU: 118 PID: 5329 en drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste No contaminado 6.12.0+ #1 (fragmento) Seguimiento de llamadas: ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? vfio_pci_config_rw+0x395/0x430 [núcleo vfio_pci] vfio_pci_rw+0x244/0x430 [núcleo vfio_pci] vfio_pci_rw+0x101/0x1b0 [núcleo vfio_pci] vfio_pci_core_read+0x1d/0x30 [núcleo vfio_pci] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: svcrdma: se corrige la falla en la destrucción de percpu_counter en svc_rdma_proc_init(). El problema es el siguiente: RPC: módulo de transporte rdma registrado. RPC: módulo de transporte de canal de retorno rdma registrado. RPC: módulo de transporte rdma no registrado. RPC: módulo de transporte de canal de retorno rdma no registrado. ERROR: no se puede gestionar el error de página para la dirección: fffffbfff80c609a PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0 Seguimiento de llamadas: __die+0x1f/0x70 page_fault_oops+0x2cd/0x860 spurious_kernel_fault+0x36/0x450 do_kern_addr_fault+0xca/0x100 exc_page_fault+0x128/0x150 asm_exc_page_fault+0x26/0x30 percpu_counter_destroy_many+0xf7/0x2a0 mmdrop+0x209/0x350 finish_task_switch.isra.0+0x481/0x840 schedule_tail+0xe/0xd0 ret_from_fork+0x23/0x80 ret_from_fork_asm+0x1a/0x30 Si register_sysctl() devuelve NULL, entonces svc_rdma_proc_cleanup() no destruirá los contadores por CPU que se inicializan en svc_rdma_proc_init(). Si CONFIG_HOTPLUG_CPU está habilitado, los nodos residuales pueden estar en la lista 'percpu_counters'. El problema anterior puede ocurrir una vez que se elimina el módulo. Si la configuración CONFIG_HOTPLUG_CPU no está habilitada, se produce una pérdida de memoria. Para resolver el problema anterior, simplemente destruya todos los contadores por CPU cuando register_sysctl() devuelva NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: evitar la desreferenciación de NULL en nfsd4_process_cb_update() @ses se inicializa a NULL. Si __nfsd4_find_backchannel() no encuentra ninguna sesión de backchannel disponible, setup_callback_client() intentará desreferenciar @ses y generar una violación de segmentación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: realtek: usb: corregir deref NULL en rtk_usb3phy_probe En rtk_usb3phy_probe(), devm_kzalloc() puede devolver NULL, pero este valor devuelto no se comprueba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: realtek: usb: corregir deref NULL en rtk_usb2phy_probe En rtk_usb2phy_probe(), devm_kzalloc() puede devolver NULL, pero este valor devuelto no se comprueba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: Se corrige el use-after-free de nreq en reqsk_timer_handler(). el commit citada reemplazó inet_csk_reqsk_queue_drop_and_put() con __inet_csk_reqsk_queue_drop() y reqsk_put() en reqsk_timer_handler(). Luego, oreq se debe pasar a reqsk_put() en lugar de req; de lo contrario, el use-after-free de nreq podría ocurrir cuando se migra reqsk pero el intento de reintento falla (por ejemplo, debido al tiempo de espera). Pasemos oreq a reqsk_put().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: MGMT: Corrige posibles bloqueos Esto corrige posibles bloqueos como el siguiente causado por hci_cmd_sync_dequeue, lo que hace que se ejecute la función de destrucción: INFO: la tarea kworker/u19:0:143 se bloqueó durante más de 120 segundos. Tainted: GWO 6.8.0-2024-03-19-intel-next-iLS-24ww14 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. tarea:kworker/u19:0 estado:D pila:0 pid:143 tgid:143 ppid:2 indicadores:0x00004000 Cola de trabajo: hci0 hci_cmd_sync_work [bluetooth] Rastreo de llamadas: __schedule+0x374/0xaf0 schedule+0x3c/0xf0 schedule_preempt_disabled+0x1c/0x30 __mutex_lock.constprop.0+0x3ef/0x7a0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3c/0x50 mgmt_set_connectable_complete+0xa4/0x150 [bluetooth] ? kfree+0x211/0x2a0 hci_cmd_sync_dequeue+0xae/0x130 [bluetooth] ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth] cmd_complete_rsp+0x26/0x80 [bluetooth] mgmt_pending_foreach+0x4d/0x70 [bluetooth] __mgmt_power_off+0x8d/0x180 [bluetooth] ? __pfx_worker_thread+0x10/0x10 kthread+0x107/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3d/0x60 ? __pfx_kthread+0x10/0x10 ret_de_fork_asm+0x1b/0x30