Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock/vmci: borre el paquete de transporte vmci correctamente al inicializarlo. En vmci_transport_packet_init, configure el vmci_transport_packet antes de completar los campos para evitar que queden datos sin inicializar en la estructura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: displayport: Soluciona un posible bloqueo El bloqueo puede ocurrir debido a una adquisición de bloqueo recursiva de `cros_typec_altmode_data::mutex`. La cadena de llamadas es la siguiente: 1. cros_typec_altmode_work() adquiere el mutex 2. typec_altmode_vdm() -> dp_altmode_vdm() -> 3. typec_altmode_exit() -> cros_typec_altmode_exit() 4. cros_typec_altmode_exit() intenta adquirir el mutex de nuevo Para evitar esto, aplaza la llamada a `typec_altmode_exit()` programándola en lugar de llamarla directamente desde dentro del contexto protegido por mutex.

Existe una vulnerabilidad de Cross-Site Scripting (XSS) reflejado en Institute-of-Current-Students v1.0 a través del parámetro de correo electrónico en el endpoint /postquerypublic. La aplicación no depura correctamente la entrada del usuario antes de reflejarla en la respuesta HTML. Esto permite a atacantes no autenticados inyectar y ejecutar código JavaScript arbitrario en el navegador de la víctima, engañándola para que visite una URL manipulada o envíe un formulario malicioso. Una explotación exitosa puede provocar secuestro de sesión, robo de credenciales u otros ataques del lado del cliente.

Se encontró una vulnerabilidad en PHPGurukul User Registration & Login and User Management 3.3, clasificada como crítica. Este problema afecta a una funcionalidad desconocida del archivo /admin/lastsevendays-reg-users.php. La manipulación del ID del argumento provoca una inyección SQL. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.

Se encontró una vulnerabilidad en PHPGurukul User Registration & Login and User Management 3.3. Se ha clasificado como crítica. Afecta una parte desconocida del archivo /admin/lastthirtyays-reg-users.php. La manipulación del ID del argumento provoca una inyección SQL. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.

Las versiones anteriores a la versión 8.9.0 de JHipster permiten la escalada de privilegios mediante un parámetro de autoridad modificado. Al registrarse en el portal de JHipster e iniciar sesión como usuario estándar, el parámetro de autoridad en la respuesta del endpoint de la API/cuenta contiene el valor ROLE_USER. Al manipular el parámetro de autoridad y cambiar su valor a ROLE_ADMIN, el privilegio se escala correctamente a nivel de administrador. Esto permite el acceso a todas las funciones administrativas de la aplicación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs: exportar anon_inode_make_secure_inode() y corregir la omisión de LSM de secretmem Exportar anon_inode_make_secure_inode() para permitir que KVM guest_memfd cree inodos anónimos con el contexto de seguridad adecuado. Esto reemplaza el patrón actual de llamar a alloc_anon_inode() seguido de inode_init_security_anon() para crear el contexto de seguridad manualmente. Este cambio también corrige una regresión de seguridad en secretmem donde el indicador S_PRIVATE no se borró después de alloc_anon_inode(), lo que provocó que se omitieran las comprobaciones de LSM/SELinux para los descriptores de archivos de secretmem. Como guest_memfd reside actualmente en el módulo KVM, necesitamos exportar este símbolo para su uso fuera del núcleo del kernel. En el futuro, guest_memfd podría moverse a core-mm, en cuyo punto los símbolos ya no tendrían que exportarse. Cuándo/si eso sucede aún no está claro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-multipath: corregir advertencia de uso sospechoso de RCU Cuando ejecuto la prueba NVME sobre TCP en virtme-ng, obtengo la siguiente advertencia de "uso sospechoso de RCU" en nvme_mpath_add_sysfs_link(): ''' [ 5.024557][ T44] nvmet: Created nvm controller 1 for subsystem nqn.2025-06.org.nvmexpress.mptcp for NQN nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77. [ 5.027401][ T183] nvme nvme0: creating 2 I/O queues. [ 5.029017][ T183] nvme nvme0: mapped 2/0/0 default/read/poll queues. [ 5.032587][ T183] nvme nvme0: new ctrl: NQN "nqn.2025-06.org.nvmexpress.mptcp", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77 [ 5.042214][ T25] [ 5.042440][ T25] ============================= [ 5.042579][ T25] WARNING: suspicious RCU usage [ 5.042705][ T25] 6.16.0-rc3+ #23 Not tainted [ 5.042812][ T25] ----------------------------- [ 5.042934][ T25] drivers/nvme/host/multipath.c:1203 RCU-list traversed in non-reader section!! [ 5.043111][ T25] [ 5.043111][ T25] other info that might help us debug this: [ 5.043111][ T25] [ 5.043341][ T25] [ 5.043341][ T25] rcu_scheduler_active = 2, debug_locks = 1 [ 5.043502][ T25] 3 locks held by kworker/u9:0/25: [ 5.043615][ T25] #0: ffff888008730948 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x7ed/0x1350 [ 5.043830][ T25] #1: ffffc900001afd40 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0xcf3/0x1350 [ 5.044084][ T25] #2: ffff888013ee0020 (&head->srcu){.+.+}-{0:0}, at: nvme_mpath_add_sysfs_link.part.0+0xb4/0x3a0 [ 5.044300][ T25] [ 5.044300][ T25] stack backtrace: [ 5.044439][ T25] CPU: 0 UID: 0 PID: 25 Comm: kworker/u9:0 Not tainted 6.16.0-rc3+ #23 PREEMPT(full) [ 5.044441][ T25] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 5.044442][ T25] Workqueue: async async_run_entry_fn [ 5.044445][ T25] Call Trace: [ 5.044446][ T25] [ 5.044449][ T25] dump_stack_lvl+0x6f/0xb0 [ 5.044453][ T25] lockdep_rcu_suspicious.cold+0x4f/0xb1 [ 5.044457][ T25] nvme_mpath_add_sysfs_link.part.0+0x2fb/0x3a0 [ 5.044459][ T25] ? queue_work_on+0x90/0xf0 [ 5.044461][ T25] ? lockdep_hardirqs_on+0x78/0x110 [ 5.044466][ T25] nvme_mpath_set_live+0x1e9/0x4f0 [ 5.044470][ T25] nvme_mpath_add_disk+0x240/0x2f0 [ 5.044472][ T25] ? __pfx_nvme_mpath_add_disk+0x10/0x10 [ 5.044475][ T25] ? add_disk_fwnode+0x361/0x580 [ 5.044480][ T25] nvme_alloc_ns+0x81c/0x17c0 [ 5.044483][ T25] ? kasan_quarantine_put+0x104/0x240 [ 5.044487][ T25] ? __pfx_nvme_alloc_ns+0x10/0x10 [ 5.044495][ T25] ? __pfx_nvme_find_get_ns+0x10/0x10 [ 5.044496][ T25] ? rcu_read_lock_any_held+0x45/0xa0 [ 5.044498][ T25] ? validate_chain+0x232/0x4f0 [ 5.044503][ T25] nvme_scan_ns+0x4c8/0x810 [ 5.044506][ T25] ? __pfx_nvme_scan_ns+0x10/0x10 [ 5.044508][ T25] ? find_held_lock+0x2b/0x80 [ 5.044512][ T25] ? ktime_get+0x16d/0x220 [ 5.044517][ T25] ? kvm_clock_get_cycles+0x18/0x30 [ 5.044520][ T25] ? __pfx_nvme_scan_ns_async+0x10/0x10 [ 5.044522][ T25] async_run_entry_fn+0x97/0x560 [ 5.044523][ T25] ? rcu_is_watching+0x12/0xc0 [ 5.044526][ T25] process_one_work+0xd3c/0x1350 [ 5.044532][ T25] ? __pfx_process_one_work+0x10/0x10 [ 5.044536][ T25] ? assign_work+0x16c/0x240 [ 5.044539][ T25] worker_thread+0x4da/0xd50 [ 5.044545][ T25] ? __pfx_worker_thread+0x10/0x10 [ 5.044546][ T25] kthread+0x356/0x5c0 [ 5.044548][ T25] ? __pfx_kthread+0x10/0x10 [ 5.044549][ T25] ? ret_from_fork+0x1b/0x2e0 [ 5.044552][ T25] ? __lock_release.isra.0+0x5d/0x180 [ 5.044553][ T25] ? ret_from_fork+0x1b/0x2e0 [ 5.044555][ T25] ? rcu_is_watching+0x12/0xc0 [ 5.044557][ T25] ? __pfx_kthread+0x10/0x10 [ 5.04 ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: spi-qpic-snand: reasignar transacciones BAM El uso del módulo mtd_nandbiterrs para probar el controlador ocasionalmente da como resultado cosas extrañas como la siguiente. 1. La asignación de swiotlb falla con el siguiente mensaje: [85.926216] qcom_snand 79b0000.spi: el búfer de swiotlb está lleno (sz: 4294967294 bytes), total 512 (ranuras), usado 0 (ranuras) [85.932937] qcom_snand 79b0000.spi: error en la asignación desc [87.999314] qcom_snand 79b0000.spi: error al escribir la página sin formato [87.999352] mtd_nandbiterrs: error: write_oob falló (-110) Reiniciar la placa después de esto provoca un pánico debido a una desreferencia de puntero NULL. 2. Si el mapeo swiotlb no falla, reiniciar la placa puede resultar en un pánico diferente debido a un spinlock magic defectuoso: [ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241 [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b ... La investigación del problema reveló que estos síntomas son resultados de la corrupción de memoria que es causada por el acceso fuera de los límites dentro del controlador. El controlador utiliza una estructura asignada dinámicamente para las transacciones BAM, dicha estructura debe tener suficiente espacio para todas las posibles variaciones de diferentes operaciones flash iniciadas por el controlador. El espacio requerido depende en gran medida del número real de 'palabras de código' que se calcula a partir del tamaño de página del chip NAND real. Aunque la función qcom_nandc_alloc() asigna memoria para las transacciones BAM durante el sondeo, pero como el número real de 'palabras de código' aún no se conoce, la asignación se realiza solo para una 'palabra de código'. Por ello, siempre que el controlador realiza una operación de flash y el número de transacciones requeridas excede el tamaño de las matrices asignadas, accede a memoria fuera del rango asignado. Para evitarlo, modifique el código para liberar la memoria de transacciones BAM inicialmente asignada y asigne una nueva una vez que se conozca el número real de palabras de código requeridas para un chip NAND determinado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port(). La función core_scsi3_decode_spec_i_port(), en su ruta de código de error, llama incondicionalmente a core_scsi3_lunacl_undepend_item() pasando el puntero dest_se_deve, que puede ser NULL. Esto puede provocar una desreferencia de puntero NULL si dest_se_deve permanece sin definir. SPC-3 PR SPEC_I_PT: No se puede ubicar dest_tpg No se puede manejar la solicitud de paginación del núcleo en la dirección virtual dfff800000000012 Rastreo de llamadas: core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P) core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod] core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod] target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod] Solucione esto agregando una comprobación NULL antes de llamar a core_scsi3_lunacl_undepend_item()

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs: Se elimina /proc/net/rpc/nfs cuando falla nfs_fs_proc_net_init(). syzbot reportó la siguiente advertencia [1] tras una inyección de fallo en nfs_fs_proc_net_init(). [0] Cuando nfs_fs_proc_net_init() falla, no se elimina /proc/net/rpc/nfs. Posteriormente, rpc_proc_exit() intenta eliminar /proc/net/rpc y la advertencia se registra porque el directorio no está vacío. Abordemos el error de nfs_fs_proc_net_init() correctamente.[0]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174) should_failslab (mm/failslab.c:46) kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204) __proc_create (fs/proc/generic.c:427) proc_create_reg (fs/proc/generic.c:554) proc_create_net_data (fs/proc/proc_net.c:120) nfs_fs_proc_net_init (fs/nfs/client.c:1409) nfs_net_init (fs/nfs/inode.c:2600) ops_init (net/core/net_namespace.c:138) setup_net (net/core/net_namespace.c:443) copy_net_ns (net/core/net_namespace.c:576) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4)) ksys_unshare (kernel/fork.c:3123) __x64_sys_unshare (kernel/fork.c:3190) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) [1]: remove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs' WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727 Modules linked in: CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727 Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00 RSP: 0018:ffffc90003637b08 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8 RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001 RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00 R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000 FS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76 ops_exit_list net/core/net_namespace.c:200 [inline] ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253 setup_net+0x2e1/0x510 net/core/net_namespace.c:457 copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574 create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218 ksys_unshare+0x45b/0xa40 kernel/fork.c:3121 __do_sys_unshare kernel/fork.c:3192 [inline] __se_sys_unshare kernel/fork.c:3190 [inline] __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa1a6b8e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtk-sd: Prevenir la corrupción de memoria por un fallo en el mapeo de DMA. Si msdc_prepare_data() no logra mapear la región DMA, la solicitud no se prepara para la recepción de datos, pero msdc_start_data() continúa el DMA con la configuración anterior. Dado que esto provocará una corrupción de memoria, debemos detener la solicitud poco después de que msdc_prepare_data() no la prepare.