Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: rechaza inodos en disco de un tipo no compatible Syzbot ha informado del siguiente ERROR: ¡ERROR del kernel en fs/inode.c:668! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 UID: 0 PID: 139 Comm: jfsCommit No contaminado 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:clear_inode+0x168/0x190 Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093 RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38 R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000 R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80 FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0 Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Esto ocurre cuando 'clear_inode()' intenta finalizar un inodo JFS subyacente de tipo desconocido. Según la descripción del diseño JFS de https://jfs.sourceforge.net/project/pub/jfslayout.pdf, los tipos de inodo del 5 al 15 están reservados para futuras extensiones y no deberían encontrarse en un sistema de archivos válido. Por lo tanto, añada una comprobación adicional para el tipo de inodo válido en 'copy_from_dinode()'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: core: Clear table_sz when rproc_shutdown Existe un caso como el siguiente que podría activar el volcado del kernel: Use U-Boot para iniciar el procesador remoto (rproc) con la tabla de recursos publicada en una dirección fija por rproc. Después de que el kernel se inicie, detenga el rproc, cargue un nuevo firmware que no tenga tabla de recursos e inicie rproc. Al iniciar rproc con un firmware que no tiene tabla de recursos, `memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` activará el volcado, porque rproc->cache_table se establece en NULL durante la última operación de detención, pero rproc->table_sz sigue siendo válido. Este problema se encuentra en i.MX8MP y i.MX9. Volcado como se muestra a continuación: No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000000 Información de aborto de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: error de traducción de nivel 0 Información de aborto de datos: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 pgtable de usuario: páginas de 4k, VA de 48 bits, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Error interno: Oops: 0000000096000004 [#1] PREEMPT Módulos SMP vinculados: CPU: 2 UID: 0 PID: 1060 Comm: sh No contaminado 6.14.0-rc7-next-20250317-dirty #38 Nombre del hardware: Placa NXP i.MX8MPlus EVK (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : Rastreo de llamadas: __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Rastreo de llamadas: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c almacén de estado+0x40/0x104 almacén de atributos de desarrollo+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invocar_llamada al sistema+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c Borre rproc->table_sz para solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: usar aead_request_free para coincidir con aead_request_alloc. Usar aead_request_free() en lugar de kfree() para liberar correctamente la memoria asignada por aead_request_alloc(). Esto garantiza que los datos criptográficos confidenciales se pongan a cero antes de liberarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: Reemplazar Mutex con Spinlock para el acceso a registros RLCG para evitar la inversión de prioridad en SRIOV. El acceso a registros RLCG es una forma de que las funciones virtuales accedan de forma segura a los registros de la GPU en un entorno virtualizado, incluyendo vaciados de TLB y lecturas de registros. Cuando varios subprocesos o VF intentan acceder a los mismos registros simultáneamente, puede provocar condiciones de ejecución. Al usar la interfaz RLCG, el controlador puede serializar el acceso a los registros. Esto significa que solo un subproceso puede acceder a los registros a la vez, lo que evita conflictos y garantiza que las operaciones se realicen correctamente. Además, cuando una tarea de baja prioridad contiene un mutex que necesita una tarea de alta prioridad (es decir, si un subproceso con un spinlock intenta adquirir un mutex), puede provocar una inversión de prioridad. El acceso a registros en amdgpu_virt_rlcg_reg_rw, especialmente en una ruta de código rápida, es crítico. La pila de llamadas muestra que se está llamando a la función amdgpu_virt_rlcg_reg_rw, que intenta adquirir el mutex. Esta función se invoca desde amdgpu_sriov_wreg, que a su vez se llama desde gmc_v11_0_flush_gpu_tlb. El error [ERROR: Contexto de espera no válido] indica que un subproceso intenta adquirir un mutex mientras se encuentra en un contexto que no le permite dormir (como mantener un spinlock). Corrige lo siguiente: [253.013423] ============================== [253.013434] [ERROR: Contexto de espera no válido] [253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Contaminado: G U OE [ 253.013464] ----------------------------- [ 253.013475] kworker/0:1/10 is trying to lock: [ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.013815] other info that might help us debug this: [ 253.013827] context-{4:4} [ 253.013835] 3 locks held by kworker/0:1/10: [ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680 [ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680 [ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu] [ 253.014154] stack backtrace: [ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14 [ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024 [ 253.014224] Workqueue: events work_for_cpu_fn [ 253.014241] Call Trace: [ 253.014250] [ 253.014260] dump_stack_lvl+0x9b/0xf0 [ 253.014275] dump_stack+0x10/0x20 [ 253.014287] __lock_acquire+0xa47/0x2810 [ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014321] lock_acquire+0xd1/0x300 [ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014562] ? __lock_acquire+0xa6b/0x2810 [ 253.014578] __mutex_lock+0x85/0xe20 [ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014782] ? sched_clock_noinstr+0x9/0x10 [ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014808] ? local_clock_noinstr+0xe/0xc0 [ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.015029] mutex_lock_nested+0x1b/0x30 [ 253.015044] ? mutex_lock_nested+0x1b/0x30 [ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu] [ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu] [ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu] [ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu] [ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu] [ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu] [ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: BPF: Corrección de error de uno en build_prologue() Vincent informó que ejecutar programas BPF con llamadas de cola en LoongArch provoca un bloqueo duro del kernel. La depuración de los problemas muestra que a la imagen JIT le falta una instrucción jirl al final del epílogo. Hay dos pasos en la compilación JIT, el primer paso establece los indicadores y el segundo paso genera código JIT basado en esos indicadores. Con programas BPF que mezclan bpf2bpf y llamadas de cola, build_prologue() genera N insns en el primer paso y luego genera N + 1 insns en el segundo paso. Esto hace que epilogue_offset se desvíe en uno y saltaremos a algún insn inesperado y causaremos un bloqueo. Arregle esto insertando un insn nop.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc: se corrigen las desreferencias NULL en ef100_process_design_param(). Desde el commit citada, ef100_probe_main() y, por lo tanto, también ef100_check_design_params() se ejecutan antes de crear efx->net_dev; por lo tanto, no podemos ejecutar netif_set_tso_max_size() ni _segs() en este momento. Traslade esas llamadas netif a ef100_probe_netdev() y reemplace netif_err en el código de parámetros de diseño por pci_err.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de lectura OOB al comprobar el directorio dotdot Montar un sistema de archivos dañado con un directorio que contiene una entrada de directorio '.' con rec_len == tamaño de bloque da como resultado una lectura fuera de los límites (más adelante, cuando se elimina el directorio dañado). ext4_empty_dir() asume que cada directorio ext4 contiene al menos '.' y '..' como entradas de directorio en el primer bloque de datos. Primero carga la entrada de directorio '.', realiza comprobaciones de cordura llamando a ext4_check_dir_entry() y luego usa su miembro rec_len para calcular la ubicación de la entrada de directorio '..' (en ext4_next_entry). Asume que la entrada de directorio '..' encaja en el mismo bloque de datos. Si el rec_len de '.' Si es exactamente un bloque (4 KB), no cumple con las comprobaciones de seguridad (se considera la última entrada de directorio del bloque de datos) y deja el puntero "struct ext4_dir_entry_2 *de" justo después de la ranura de memoria asignada al bloque de datos. La siguiente llamada a ext4_check_dir_entry() con el nuevo valor de de desreferencia este puntero, lo que resulta en un acceso a la memoria fuera de los límites. Para solucionar esto, extienda __ext4_check_dir_entry() para verificar las entradas de directorio "." que llegan al final del bloque de datos. Asegúrese de ignorar las entradas de directorio falsas para la suma de comprobación (verificando name_len para ver si es distinto de cero). Nota: KASAN informa que esto es un use-after-free en caso de que otra estructura se haya liberado recientemente de la ranura más allá del límite, pero en realidad es una lectura fuera de banda (OOB). Este problema fue detectado por la herramienta syzkaller. Rastreo de llamadas: [38.594108] ERROR: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e

Se encontró una vulnerabilidad crítica en SourceCodester Web-based Pharmacy Product Management System 1.0. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /add-product.php. La manipulación del argumento Avatar permite la carga sin restricciones. El ataque puede ejecutarse remotamente. Se ha hecho público el exploit y puede que sea utilizado.

El complemento Coupon Affiliates – Affiliate Plugin for WooCommerce para WordPress es vulnerable a ataques de Cross-Site Scripting Reflejado a través del parámetro commission_summary en todas las versiones hasta la 6.3.0 incluida, debido a una depuración de entrada y al escape de salida insuficiente. Esto permite a atacantes no autenticados inyectar scripts web arbitrarios en páginas que se ejecutan si logran engañar al usuario para que realice una acción, como hacer clic en un enlace.

El complemento MapPress Maps para WordPress anterior a la versión 2.94.10 no depura ni escapa de algunas de sus configuraciones, lo que podría permitir a usuarios con privilegios elevados, como el administrador, realizar ataques de Cross Site Scripting almacenado incluso cuando la capacidad unfiltered_html no está permitida (por ejemplo, en una configuración de varios sitios).

Se han detectado configuraciones predeterminadas inseguras en los registradores de Yokogawa Electric Corporation. La función de autenticación está deshabilitada por defecto en los productos afectados. Por lo tanto, al conectarse a una red con la configuración predeterminada, cualquier persona puede acceder a todas las funciones relacionadas con la configuración y las operaciones. Como resultado, un atacante puede manipular y configurar ilegalmente datos importantes, como valores medidos y configuraciones. Este problema afecta a los registradores sin papel GX10/GX20/GP10/GP20: R5.04.01 o anteriores; Sistema de adquisición de datos GM: R5.05.01 o anteriores; Registradores sin papel DX1000/DX2000/DX1000N: R4.21 o anteriores; Registradores sin papel FX1000: R1.31 o anteriores; Registradores de gráficos ?R10000/?R20000: R1.51 o anteriores; Unidades de adquisición de datos MW100: Todas las versiones. Registradores sin papel DX1000T / DX2000T: todas las versiones; Registradores sin papel CX1000 / CX2000: todas las versiones.

La vulnerabilidad de neutralización incorrecta de la entrada durante la generación de páginas web ('Cross-site Scripting') en Pantherius Modal Survey permite XSS reflejado. Este problema afecta a Modal Survey: desde n/a hasta 2.0.2.0.1.