Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: validar el prefijo de la nueva SA usando la familia de SA cuando sel.family no está configurado Esto expande la validación introducida en el commit 07bf7908950a ("xfrm: validar las longitudes de prefijo de dirección en el selector xfrm"). syzbot creó una SA con usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Debido al selector AF_UNSPEC, verificar_newsa_info no pone límites en prefixlen_{s,d}. Pero luego copy_from_user_state establece x->sel.family en usersa.family (AF_INET). Realice la misma conversión en verificar_newsa_info antes de validar prefixlen_{s,d}, ya que así es como se usará prefixlen más adelante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: bnep: corrige wild-memory-access en proto_unregister Hay un problema como el siguiente: KASAN: tal vez wild-memory-access en el rango [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: GW RIP: 0010:proto_unregister+0xee/0x400 Seguimiento de llamadas: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Como bnep_init() ignora el valor de retorno de bnep_sock_init(), y bnep_sock_init() limpiará Todos los recursos. Luego, cuando se elimine el módulo bnep, se llamará a bnep_sock_cleanup() para limpiar el recurso de Sock. Para resolver el problema anterior, simplemente devuelva el valor de retorno de bnep_sock_init() en bnep_exit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: altmode debería mantener la referencia al padre La versión del dispositivo altmode hace referencia a su dispositivo padre, pero sin mantener una referencia a él. Al registrar el altmode, se obtiene una referencia al padre y se coloca en la función de lanzamiento. Antes de esta corrección, al usar CONFIG_DEBUG_KOBJECT_RELEASE, vemos problemas como este: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, padre 0000000000000000 (retrasado 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, padre 0000000000000000 (retrasado 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, padre 000000000000000 (retrasado 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, padre 0000000000000000 (retrasado 3000) [ 46.612867] ======================================================================= [ 46.613402] ERROR: KASAN: slab-use-after-free en typec_altmode_release+0x38/0x129 [ 46.614003] Lectura de tamaño 8 en la dirección ffff8880057b9118 por la tarea kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 No contaminado 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Cola de trabajo: eventos kobject_delayed_cleanup [ 46.616446] Seguimiento de llamadas: [ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? proceso_trabajo_programado+0x3cb/0x85f [ 46.620185] tipoc_modo_alt_release+0x38/0x129 [ 46.620537] ? proceso_trabajo_programado+0x3cb/0x85f [ 46.620907] dispositivo_release+0xaf/0xf2 [ 46.621206] limpieza_retrasada_de_objetos+0x13b/0x17a [ 46.621584] proceso_trabajo_programado+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] subproceso de trabajo+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] [ 46.625953] [ 46.626056] Asignado por la tarea 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Liberado por la tarea 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corregir OOB al crear una solicitud SMB2_IOCTL Al usar cifrado, ya sea aplicado por el servidor o al usar la opción de montaje 'seal', el cliente comprimirá todos los buffers de solicitud compuestos para el cifrado en un solo iov en smb2_set_next_command(). SMB2_ioctl_init() asigna un pequeño búfer (448 bytes) para contener la solicitud SMB2_IOCTL en el primer iov, y si el usuario pasa un búfer de entrada que es mayor a 328 bytes, smb2_set_next_command() terminará escribiendo el final de @rqst->iov[0].iov_base como se muestra a continuación: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link ERROR: KASAN: slab-out-of-bounds en smb2_set_next_command.cold+0x1d6/0x24c [cifs] Escritura de tamaño 4116 en la dirección ffff8881148fcab8 por tarea ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln No contaminado 6.12.0-rc3 #1 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? vfs_symlink+0x1a1/0x2c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] ? smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? __buscar_bloqueo_mantenido+0x8a/0xa0 ? __hlock_class+0x32/0xb0 ? __ruta_de_compilación_desde_dentry_prefijo_opcional+0x19d/0x2e0 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? permiso_genérico+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entrada_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: core: Corregir null-ptr-deref en target_alloc_device() KASAN ha informado de un problema de null-ptr-deref: ERROR: KASAN: null-ptr-deref en target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e En target_alloc_device(), si falla la asignación de memoria para las colas dev, dev se liberará mediante dev->transport->free_device(), pero dev->transport no se inicializa en ese momento, lo que generará un problema de referencia de puntero nulo. Se soluciona este error liberando dev con hba->backend->ops->free_device().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: Corregir error de desplazamiento fuera de los límites Corrige un error de desplazamiento fuera de los límites informado por UBSAN al ejecutar una máquina virtual con un kernel de host habilitado para MTE. UBSAN: desplazamiento fuera de los límites en arch/arm64/kvm/sys_regs.c:1988:14 el exponente de desplazamiento 33 es demasiado grande para el tipo de 32 bits 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm No contaminado 6.12.0-rc2 #34 Nombre del hardware: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 14/10/2024 Seguimiento de llamadas: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x74/0x90 dump_stack+0x18/0x28 __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0 reset_clidr+0x10c/0x1c8 kvm_reset_sys_regs+0x50/0x1c8 kvm_reset_vcpu+0xec/0x2b0 __kvm_vcpu_set_target+0x84/0x158 kvm_vcpu_set_target+0x138/0x168 kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0 kvm_arch_vcpu_ioctl+0x28c/0x4b8 kvm_vcpu_ioctl+0x4bc/0x7a8 __arm64_sys_ioctl+0xb4/0x100 invocar_llamada_al_sistema+0x70/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/core: Deshabilitar la asignación de páginas en task_tick_mm_cid() Con KASAN y PREEMPT_RT habilitados, llamar a task_work_add() en task_tick_mm_cid() puede causar el siguiente splat. [ 63.696416] ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 [ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe [ 63.696416] preempt_count: 10001, esperado: 0 [ 63.696416] Profundidad de anidación de RCU: 1, esperado: 1 Este problema es causado por el siguiente seguimiento de llamada. sched_tick() [ adquirir rq->__lock ] -> task_tick_mm_cid() -> task_work_add() -> __kasan_record_aux_stack() -> kasan_save_stack() -> stack_depot_save_flags() -> alloc_pages_mpol_noprof() -> __alloc_pages_noprof() -> get_page_from_freelist() -> rmqueue() -> rmqueue_pcplist() -> __rmqueue_pcplist() -> rmqueue_bulk() -> rt_spin_lock() El bloqueo rq es un raw_spinlock_t. No podemos dormir mientras lo mantenemos. Es decir, no podemos llamar a alloc_pages() en stack_depot_save_flags(). La función task_tick_mm_cid() con su llamada task_work_add() fue introducida por el commit 223baf9d17f2 ("sched: Fix performance regression presented by mm_cid") en el kernel v6.4. Afortunadamente, hay una variante kasan_record_aux_stack_noalloc() que llama a stack_depot_save_flags() pero no le permite asignar nuevas páginas. Para permitir que task_tick_mm_cid() use task_work sin asignación de páginas, se agrega un nuevo indicador TWAF_NO_ALLOC para habilitar la llamada a kasan_record_aux_stack_noalloc() en lugar de kasan_record_aux_stack() si está configurado. La función task_tick_mm_cid() se modifica para agregar este nuevo indicador. La posible desventaja es la falta de seguimiento de pila en un informe KASAN debido a la nueva asignación de página requerida cuando se llama a task_work_add_noallloc(), lo que debería ser poco común.

Las versiones 11.3.2416.21 y anteriores, 11.3.2428.9 y anteriores de Zohocorp ManageEngine EndPoint Central son vulnerables a la eliminación arbitraria de archivos en las máquinas instaladas por el agente.

Se encontró una falla en el paquete Undertow. Mediante el uso de FormAuthenticationMechanism, un usuario malintencionado podría provocar una denegación de servicio mediante el envío de solicitudes manipuladas, lo que provocaría un error de falta de memoria en el servidor y agotaría su memoria.

Se encontró una falla en el método 'isValid' de hibernate-validator en la clase org.hibernate.validator.internal.constraintvalidators.hv.SafeHtmlValidator, que se puede evitar omitiendo la etiqueta que termina en un carácter menor que. Los navegadores pueden mostrar un código HTML no válido, lo que permite la inyección de HTML o ataques de Cross-Site-Scripting (XSS).

HCL BigFix Compliance se ve afectado por redirecciones y reenvíos no validados. El encabezado HOST puede ser manipulado por un atacante y, como resultado, puede contaminar la memoria caché web y devolver la página a los usuarios.

HCL BigFix Compliance es vulnerable a la generación de mensajes de error que contienen información confidencial. Los mensajes de error detallados pueden proporcionar información incitativa o exponer información sobre su entorno, usuarios o datos asociados.