Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netmem: evitar TX de skbs ilegibles Actualmente en árboles estables tenemos soporte para netmem/devmem RX pero no TX. No es seguro reenviar/redirigir un paquete netmem ilegible RX en la ruta TX del dispositivo, ya que el dispositivo puede llamar a las API de mapeo DMA en direcciones DMA que no se le deben pasar. Arregle esto al evitar la xmit de skbs ilegibles. Probado al configurar tc redirect: sudo tc qdisc add dev eth1 ingress sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ip_proto \ tcp src_ip 192.168.1.12 action mirred egress redirect dev eth1 Antes, veía skbs ilegibles en la ruta TX del controlador pasada a las API de mapeo DMA. Después, no veo skbs ilegibles en la ruta TX del controlador pasada a las API de mapeo de DMA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: impide la liberación de la conexión durante la notificación de interrupción del bloqueo de oplock. ksmbd_work podría liberarse después de la liberación de la conexión. Incremente r_count de ksmbd_conn para indicar que las solicitudes aún no han finalizado y para no liberar la conexión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Establecer la dirección base mmap de hugetlb alineada con el tamaño de pmd Con el caso de prueba ltp "testcases/bin/hugefork02", hay un mensaje de informe de error dmesg como: ¡ERROR del kernel en mm/hugetlb.c:5550! Ups - BUG[#1]: CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 No contaminado 6.14.0-rc2+ #241 Nombre del hardware: QEMU Máquina virtual QEMU, BIOS desconocido 2/2/2022 pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940 a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000 a4 000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000 t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000 t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 000000000000001 t8 000000000000005 u0 9000000004849d0 s9 900000010edbfa00 s0 9000000108d20280 s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10 s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08 ra: 9000000000485538 unmap_vmas+0x130/0x218 ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0 PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EssubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Proceso hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64) Seguimiento de llamadas: [<90000000004eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0 [<9000000000485534>] unmap_vmas+0x12c/0x218 [<9000000000494068>] exit_mmap+0xe0/0x308 [<900000000025fdc4>] mmput+0x74/0x180 [<900000000026a284>] do_exit+0x294/0x898 [<900000000026aa30>] do_group_exit+0x30/0x98 [<900000000027bed4>] get_signal+0x83c/0x868 [<90000000002457b4>] arch_do_signal_or_restart+0x54/0xfa0 [<90000000015795e8>] irqentry_exit_to_user_mode+0xb8/0x138 [<90000000002572d0>] tlb_do_page_fault_1+0x114/0x1b4 El problema radica en que la dirección base asignada desde hugetlbfs no está alineada con el tamaño de pmd. Añada una comprobación para hugetlbfs y alinee la dirección base con el tamaño de pmd. Después de esta corrección, el caso de prueba "testcases/bin/hugefork02" pasa a ejecución. Esto es similar a el commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: enseñar a generic_get_unmapped_area{_topdown} a manejar asignaciones hugetlb").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: cleanup struct mana después de debugfs_remove(). Cuando se activa la hibernación en una máquina virtual MANA, como parte de hibernate_snapshot(), se invocan mana_gd_suspend() y mana_gd_resume(). Si durante este mana_gd_resume() se produce un fallo en la creación de HWC, el puntero mana_port_debugfs no se reinicializa y termina apuntando a una dentry anterior y limpiada. Más adelante en la ruta de hibernación, como parte de power_down(), se activa mana_gd_shutdown(). Esta llamada, sin tener conocimiento de los fallos en la reanudación, intenta limpiar el valor mana_port_debugfs ya limpiado y se encuentra con el siguiente error: [ 191.359296] mana 7870:00:00.0: Se llamó al apagado [ 191.359918] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000098 [ 191.360584] #PF: acceso de escritura del supervisor en modo kernel [ 191.361125] #PF: error_code(0x0002) - página no presente [ 191.361727] PGD 1080ea067 P4D 0 [ 191.362172] Oops: Oops: 0002 [#1] SMP NOPTI [ 191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash No contaminado 6.14.0-rc5+ #2 [ 191.363292] Nombre del hardware: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 21/11/2024 [ 191.364124] RIP: 0010:down_write+0x19/0x50 [ 191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d [ 191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246 [ 191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000 [ 191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098 [ 191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001 [ 191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000 [ 191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020 [ 191.369549] FS: 00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000 [ 191.370213] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0 [ 191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 191.372906] Call Trace: [ 191.373262] [ 191.373621] ? show_regs+0x64/0x70 [ 191.374040] ? __die+0x24/0x70 [ 191.374468] ? page_fault_oops+0x290/0x5b0 [ 191.374875] ? do_user_addr_fault+0x448/0x800 [ 191.375357] ? exc_page_fault+0x7a/0x160 [ 191.375971] ? asm_exc_page_fault+0x27/0x30 [ 191.376416] ? down_write+0x19/0x50 [ 191.376832] ? down_write+0x12/0x50 [ 191.377232] simple_recursive_removal+0x4a/0x2a0 [ 191.377679] ? __pfx_remove_one+0x10/0x10 [ 191.378088] debugfs_remove+0x44/0x70 [ 191.378530] mana_detach+0x17c/0x4f0 [ 191.378950] ? __flush_work+0x1e2/0x3b0 [ 191.379362] ? __cond_resched+0x1a/0x50 [ 191.379787] mana_remove+0xf2/0x1a0 [ 191.380193] mana_gd_shutdown+0x3b/0x70 [ 191.380642] pci_device_shutdown+0x3a/0x80 [ 191.381063] device_shutdown+0x13e/0x230 [ 191.381480] kernel_power_off+0x35/0x80 [ 191.381890] hibernate+0x3c6/0x470 [ 191.382312] state_store+0xcb/0xd0 [ 191.382734] kobj_attr_store+0x12/0x30 [ 191.383211] sysfs_kf_write+0x3e/0x50 [ 191.383640] kernfs_fop_write_iter+0x140/0x1d0 [ 191.384106] vfs_write+0x271/0x440 [ 191.384521] ksys_write+0x72/0xf0 [ 191.384924] __x64_sys_write+0x19/0x20 [ 191.385313] x64_sys_call+0x2b0/0x20b0 [ 191.385736] do_syscall_64+0x79/0x150 [ 191.386146] ? __mod_memcg_lruvec_state+0xe7/0x240 [ 191.386676] ? __lruvec_stat_mod_folio+0x79/0xb0 [ 191.387124] ? __pfx_lru_add+0x10/0x10 [ 191.387515] ? queued_spin_unlock+0x9/0x10 [ 191.387937] ? do_anonymous_page+0x33c/0xa00 [ 191.388374] ? __handle_mm_fault+0xcf3/0x1210 [ 191.388805] ? __count_memcg_events+0xbe/0x180 [ 191.389235] ? handle_mm_fault+0xae/0x300 [ 19 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: virt: acrn: hsm: Usar kzalloc para evitar fugas de información en pmcmd_ioctl. En la función "pmcmd_ioctl", tres objetos de memoria asignados por kmalloc se inicializan mediante "hcall_get_cpu_state", que posteriormente se copian al espacio de usuario. El inicializador está implementado en "acrn_hypercall2" (arch/x86/include/asm/acrn.h). Existe riesgo de fuga de información debido a bytes no inicializados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: host: pci_generic: Use pci_try_reset_function() para evitar el interbloqueo Hay varios lugares desde donde el trabajo de recuperación se programa de forma asíncrona. Además, hay varios lugares donde el llamador espera de forma síncrona a que se complete la recuperación. Uno de esos lugares es durante la devolución de llamada de PM shutdown(). Si el dispositivo no está activo durante recovery_work, intentará reiniciar el dispositivo utilizando pci_reset_function(). Esta función tomará internamente primero device_lock() antes de reiniciar el dispositivo. En este momento, si el bloqueo ya se ha adquirido, entonces recovery_work se detendrá mientras espera el bloqueo. Y si el bloqueo ya fue adquirido por el llamador que espera a que se complete recovery_work, provocará un interbloqueo. Esto es lo que ocurrió en el dispositivo X1E80100 CRD cuando el dispositivo murió antes de la devolución de llamada de shutdown(). El núcleo del controlador llama a la devolución de llamada de apagado () del controlador mientras mantiene el device_lock(), lo que provoca un interbloqueo. Este bloqueo también puede ocurrir en otras rutas, como durante la devolución de llamada suspend() de PM, donde el núcleo del controlador mantendría el bloqueo_de_dispositivo() antes de llamar a la devolución de llamada suspend() del controlador. Si el trabajo de recuperación ya se había iniciado, podría provocar un bloqueo. Esto también se observa en el CRD X1E80100. Para solucionar ambos problemas, utilice pci_try_reset_function() en el trabajo de recuperación. Esta función primero comprueba la disponibilidad del bloqueo_de_dispositivo() antes de intentar reiniciar el dispositivo. Si el bloqueo está disponible, lo adquirirá y reiniciará el dispositivo. De lo contrario, devolverá -EAGAIN. En este caso, el trabajo de recuperación fallará con el mensaje de error "Error de recuperación", ya que no se pudo hacer mucho.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Asignar normalized_pix_clk cuando la profundidad de color es 14 [POR QUÉ Y CÓMO] Se produce un mensaje de advertencia "ADVERTENCIA: CPU: 4 PID: 459 en ... /dc_resource.c:3397 calculate_phy_pix_clks+0xef/0x100 [amdgpu]" porque no se gestiona la profundidad de color de la pantalla = COLOR_DEPTH_141414. Esto se observa en la Radeon RX 6600 XT. Se soluciona asignando pix_clk * (14 * 3) / 24, igual que el resto. También se corrige la sangría en get_norm_pix_clk. (Seleccionado de el commit 274a87eb389f58eddcbc5659ab0b180b37e92775)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla1280: Se corrige el error del kernel cuando el nivel de depuración > 2. Eventualmente, se producirá una desreferencia nula o una excepción de error cuando el controlador qla1280.c se compila con DEBUG_QLA1280 habilitado y ql_debug_level > 2. Creo que del código se desprende claramente que la intención aquí es sg_dma_len(s), no la longitud de sg_next(s) al imprimir la información de depuración.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: fix extent range end unlock in cow_file_range(). Ejecutar generic/751 en la rama for-next suele provocar un bloqueo como el que se muestra a continuación. Ambas se acumulan bloqueando una extensión. Esto sugiere que alguien olvidó desbloquear una extensión. INFORMACIÓN: La tarea kworker/u128:1:12 se bloqueó durante más de 323 segundos. No contaminada. 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:kworker/u128:1 estado:D pila:0 pid:12 tgid:12 ppid:2 indicadores:0x00004000 Cola de trabajo: btrfs-fixup btrfs_work_helper [btrfs] Rastreo de llamadas: __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs] btrfs_work_helper+0xff/0x480 [btrfs] ? lock_release+0x178/0x2c0 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 INFO: task kworker/u134:0:184 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u134:0 state:D stack:0 pid:184 tgid:184 ppid:2 flags:0x00004000 Workqueue: writeback wb_workfn (flush-btrfs-4) Call Trace: __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 find_lock_delalloc_range+0xdb/0x260 [btrfs] writepage_delalloc+0x12f/0x500 [btrfs] ? srso_return_thunk+0x5/0x5f extent_write_cache_pages+0x232/0x840 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xe7/0x260 ? srso_return_thunk+0x5/0x5f ? lock_acquire+0xd2/0x300 ? srso_return_thunk+0x5/0x5f ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 __writeback_single_inode+0x5c/0x4b0 writeback_sb_inodes+0x22d/0x550 __writeback_inodes_wb+0x4c/0xe0 wb_writeback+0x2f6/0x3f0 wb_workfn+0x32a/0x510 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Esto sucede porque tenemos otra ruta de éxito para el modo zonificado. Cuando no hay ninguna zona activa disponible, btrfs_reserve_extent() devuelve -EAGAIN. En este caso, tenemos dos reacciones. (1) Si el rango dado nunca se asigna, solo podemos esperar a que alguien complete una zona, por lo que esperamos el bit BTRFS_FS_NEED_ZONE_FINISH y reintentamos después. (2) O bien, si ya se han realizado algunas asignaciones, debemos abandonar y dejar que el llamador envíe E/S para la asignación. Esto se debe a que estas E/S pueden ser necesarias para completar una zona. El commit 06f364284794 ("btrfs: realizar la limpieza de folio correcta cuando cow_file_range() falla") movió el código de desbloqueo del interior del bucle al exterior. Por lo tanto, antes, las extensiones asignadas se desbloqueaban justo después de la asignación y, por lo tanto, antes de regresar de la función. Sin embargo, ya no se desbloquean en el caso (2) mencionado. Esto causó el bloqueo. Para solucionar el problema, modifique "end" al final del rango asignado. De esta manera, podemos salir del bucle y el mismo código de desbloqueo puede gestionar el caso correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige un error fuera de los límites en parse_sec_desc(). Si osidoffset, gsidoffset y dacloffset pueden ser mayores que el tamaño de la estructura smb_ntsd, si es menor, podría causar un error fuera de los límites de slab. Al validar sid, es necesario comprobar si incluye el tamaño del array subauth.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: gregator: protege los controladores attr del controlador contra la descarga del módulo Tanto new_device_store como delete_device_store tocan los recursos globales del módulo (por ejemplo, gpio_aggregator_lock). Para evitar condiciones de ejecución con la descarga del módulo, se debe mantener una referencia. Agregue try_module_get() en estos controladores. Para new_device_store, esto elimina lo que parece ser el escenario más peligroso: si se asigna un id desde gpio_aggregator_idr pero platform_device_register aún no se ha llamado o completado, una descarga de módulo concurrente podría fallar al anular el registro/eliminar el dispositivo, dejando atrás un reenvío de dispositivo de plataforma/GPIO colgante. Esto puede resultar en varios problemas. El siguiente reproductor simple demuestra estos problemas: #!/bin/bash while :; do # nota: no importa si 'gpiochip0 0' existe o no. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait A partir de la siguiente advertencia, aparecerán varios tipos de advertencias y el sistema puede volverse inestable: ------------[ cortar aquí ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ fin de seguimiento 000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige un error en la trampa de smb2_lock. Si el número de bloqueos es mayor que 1, las banderas podrían tener un valor anterior. Debe comprobarse con las banderas de smb_lock, no con las banderas. Esto provocará un error en la trampa de locks_free_lock en la rutina de gestión de errores.