Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de la ejecución entre el trabajador de recuperación asíncrono y close_ctree() Syzbot informó de un error de aserción debido a un intento de agregar una entrada retrasada después de que hayamos establecido BTRFS_FS_STATE_NO_DELAYED_IPUT en el estado WARNING: CPU: 0 PID: 65 at fs/btrfs/inode.c:3420 btrfs_add_delayed_iput+0x2f8/0x370 fs/btrfs/inode.c:3420 Modules linked in: CPU: 0 UID: 0 PID: 65 Comm: kworker/u8:4 Not tainted 6.15.0-next-20250530-syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Workqueue: btrfs-endio-write btrfs_work_helper RIP: 0010:btrfs_add_delayed_iput+0x2f8/0x370 fs/btrfs/inode.c:3420 Code: 4e ad 5d (...) RSP: 0018:ffffc9000213f780 EFLAGS: 00010293 RAX: ffffffff83c635b7 RBX: ffff888058920000 RCX: ffff88801c769e00 RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000000 RBP: 0000000000000001 R08: ffff888058921b67 R09: 1ffff1100b12436c R10: dffffc0000000000 R11: ffffed100b12436d R12: 0000000000000001 R13: dffffc0000000000 R14: ffff88807d748000 R15: 0000000000000100 FS: 0000000000000000(0000) GS:ffff888125c53000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ---truncado--- Call Trace: btrfs_put_ordered_extent+0x19f/0x470 fs/btrfs/ordered-data.c:635 btrfs_finish_one_ordered+0x11d8/0x1b10 fs/btrfs/inode.c:3312 btrfs_work_helper+0x399/0xc20 fs/btrfs/async-thread.c:312 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Esto puede suceder debido a una ejecución con el trabajador de recuperación asíncrono como este: 1) El trabajador de recuperación de metadatos asíncrono ingresa a shrink_delalloc(), que llama a btrfs_start_delalloc_roots() con un argumento nr_pages que tiene un valor menor que LONG_MAX, y que a su vez ingresa a start_delalloc_inodes(), que establece la variable local 'full_flush' en falso porque wbc->nr_to_write es menor que LONG_MAX; 2) Allí encuentra el inodo X en una lista delalloc de la raíz, toma una referencia para el inodo X (con igrab()), y activa la escritura diferida para él con filemap_fdatawrite_wbc(), que crea una extensión ordenada para el inodo X; 3) La secuencia de desmontaje comienza desde otra tarea, ingresamos close_ctree() y limpiamos la cola de trabajo fs_info->endio_write_workers, que espera a que se complete la extensión ordenada para el inodo X y cuando eliminamos la última referencia de la extensión ordenada, con btrfs_put_ordered_extent(), cuando llamamos a btrfs_add_delayed_iput() no agregamos el inodo a la lista de entradas retrasadas porque tiene un refcount de 2, por lo que lo decrementamos a 1 y regresamos; 4) Poco después, en close_ctree(), llamamos a btrfs_run_delayed_iputs(), que ejecuta todas las entradas retrasadas, y luego establecemos BTRFS_FS_STATE_NO_DELAYED_IPUT en el estado fs_info. 5) El trabajador de recuperación asíncrono, después de llamar a filemap_fdatawrite_wbc(), ahora llama a btrfs_add_delayed_iput() para el inodo X y allí desencadenamos un error de aserción, ya que el estado fs_info tiene el indicador BTRFS_FS_STATE_NO_DELAYED_IPUT establecido. Solucione esto estableciendo BTRFS_FS_STATE_NO_DELAYED_IPUT solo después de esperar a que finalicen los trabajadores de recuperación asíncronos, después de llamar a cancel_work_sync() para ellos en close_ctree(), y ejecutando las entradas retrasadas después de esperar a que finalicen los trabajadores de recuperación y antes de establecer el bit. Esta ejecución se introdujo recientemente mediante el commit 19e60b2a95f5 ("btrfs: añadir una advertencia adicional si se añade una entrada retardada cuando no está permitida"). Sin la nueva validación en btrfs_add_delayed_iput(), ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fuse: corrección de la advertencia de tiempo de ejecución en truncate_folio_batch_exceptionals(). Se introduce WARN_ON_ONCE en truncate_folio_batch_exceptionals() para detectar si el sistema de archivos ha eliminado todas las entradas DAX. La corrección se ha aplicado a los sistemas de archivos xfs y ext4 mediante el commit 0e2f80afcfa6 ("fs/dax: asegurar que todas las páginas estén inactivas antes de desmontar el sistema de archivos"). Aplique la corrección que faltó en el fusible del sistema de archivos para corregir la advertencia de tiempo de ejecución: [ 2.011450] ------------[ cut here ]------------ [ 2.011873] WARNING: CPU: 0 PID: 145 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0x272/0x2b0 [ 2.012468] Modules linked in: [ 2.012718] CPU: 0 UID: 1000 PID: 145 Comm: weston Not tainted 6.16.0-rc2-WSL2-STABLE #2 PREEMPT(undef) [ 2.013292] RIP: 0010:truncate_folio_batch_exceptionals+0x272/0x2b0 [ 2.013704] Code: 48 63 d0 41 29 c5 48 8d 1c d5 00 00 00 00 4e 8d 6c 2a 01 49 c1 e5 03 eb 09 48 83 c3 08 49 39 dd 74 83 41 f6 44 1c 08 01 74 ef <0f> 0b 49 8b 34 1e 48 89 ef e8 10 a2 17 00 eb df 48 8b 7d 00 e8 35 [ 2.014845] RSP: 0018:ffffa47ec33f3b10 EFLAGS: 00010202 [ 2.015279] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 2.015884] RDX: 0000000000000000 RSI: ffffa47ec33f3ca0 RDI: ffff98aa44f3fa80 [ 2.016377] RBP: ffff98aa44f3fbf0 R08: ffffa47ec33f3ba8 R09: 0000000000000000 [ 2.016942] R10: 0000000000000001 R11: 0000000000000000 R12: ffffa47ec33f3ca0 [ 2.017437] R13: 0000000000000008 R14: ffffa47ec33f3ba8 R15: 0000000000000000 [ 2.017972] FS: 000079ce006afa40(0000) GS:ffff98aade441000(0000) knlGS:0000000000000000 [ 2.018510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.018987] CR2: 000079ce03e74000 CR3: 000000010784f006 CR4: 0000000000372eb0 [ 2.019518] Call Trace: [ 2.019729] [ 2.019901] truncate_inode_pages_range+0xd8/0x400 [ 2.020280] ? timerqueue_add+0x66/0xb0 [ 2.020574] ? get_nohz_timer_target+0x2a/0x140 [ 2.020904] ? timerqueue_add+0x66/0xb0 [ 2.021231] ? timerqueue_del+0x2e/0x50 [ 2.021646] ? __remove_hrtimer+0x39/0x90 [ 2.022017] ? srso_alias_untrain_ret+0x1/0x10 [ 2.022497] ? psi_group_change+0x136/0x350 [ 2.023046] ? _raw_spin_unlock+0xe/0x30 [ 2.023514] ? finish_task_switch.isra.0+0x8d/0x280 [ 2.024068] ? __schedule+0x532/0xbd0 [ 2.024551] fuse_evict_inode+0x29/0x190 [ 2.025131] evict+0x100/0x270 [ 2.025641] ? _atomic_dec_and_lock+0x39/0x50 [ 2.026316] ? __pfx_generic_delete_inode+0x10/0x10 [ 2.026843] __dentry_kill+0x71/0x180 [ 2.027335] dput+0xeb/0x1b0 [ 2.027725] __fput+0x136/0x2b0 [ 2.028054] __x64_sys_close+0x3d/0x80 [ 2.028469] do_syscall_64+0x6d/0x1b0 [ 2.028832] ? clear_bhb_loop+0x30/0x80 [ 2.029182] ? clear_bhb_loop+0x30/0x80 [ 2.029533] ? clear_bhb_loop+0x30/0x80 [ 2.029902] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 2.030423] RIP: 0033:0x79ce03d0d067 [ 2.030820] Code: b8 ff ff ff ff e9 3e ff ff ff 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 c3 a7 f8 ff [ 2.032354] RSP: 002b:00007ffef0498948 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ 2.032939] RAX: ffffffffffffffda RBX: 00007ffef0498960 RCX: 000079ce03d0d067 [ 2.033612] RDX: 0000000000000003 RSI: 0000000000001000 RDI: 000000000000000d [ 2.034289] RBP: 00007ffef0498a30 R08: 000000000000000d R09: 0000000000000000 [ 2.034944] R10: 00007ffef0498978 R11: 0000000000000246 R12: 0000000000000001 [ 2.035610] R13: 00007ffef0498960 R14: 000079ce03e09ce0 R15: 0000000000000003 [ 2.036301] [ 2.036532] ---[ end trace 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/gpu: se corrige el fallo que se produce al limitar la GPU inmediatamente durante el arranque. Existe una pequeña posibilidad de que la GPU ya esté caliente durante el arranque. En ese caso, la llamada a of_devfreq_cooling_register() intentará inmediatamente aplicar el enfriamiento devfreq, como se ve en el siguiente fallo: No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ... En este punto, aún no hemos inicializado la GMU en absoluto, por lo que no podemos leer los registros de la GMU dentro de a6xx_gpu_busy(). Un problema similar se solucionó previamente en el commit 6694482a70e9 ("drm/msm: Evitar el acceso a registros de GMU sin reloj en 6xx gpu_busy"): msm_devfreq_init() llama a devfreq_suspend_device(), pero a diferencia de msm_devfreq_suspend(), no establece el indicador df->suspended como corresponde. Esto significa que el indicador df->suspended no coincide con el estado real de devfreq tras la inicialización y msm_devfreq_get_dev_status() accederá a los registros de GMU, lo que provocará el bloqueo. Para solucionarlo, configure df->suspended correctamente durante la inicialización. Patchwork: https://patchwork.freedesktop.org/patch/650772/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Comprobar dce_hwseq antes de desreferenciarlo [WHAT] hws se verificó para nulo anteriormente en dce110_blank_stream, lo que indica que hws puede ser nulo y debe verificarse siempre que se use. (seleccionado del commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Se corrige la toma de un bloqueo no válido en una cuña. Si el dispositivo realiza una cuña durante, por ejemplo, la carga de GuC, el envío aún no está habilitado y el estado ni siquiera se inicializa. Se protege la llamada a la cuña para que no haga nada en este caso. Corrige el siguiente problema: [] xe 0000:bf:00.0: [drm] device wedged, needs recovery [] ------------[ cut here ]------------ [] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60 ... [] RIP: 0010:__mutex_lock+0x8a1/0xe60 [] mutex_lock_nested+0x1b/0x30 [] xe_guc_submit_wedge+0x80/0x2b0 [xe]

Se ha detectado una vulnerabilidad en D-Link DCS-6010L 1.15.03, clasificada como problemática. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /vb.htm del componente Aplicación de Gestión. La manipulación del argumento paratest provoca cross site scripting. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Esta vulnerabilidad solo afecta a los productos que ya no reciben soporte del fabricante.

Vulnerabilidad de neutralización incorrecta de entrada durante la generación de páginas web (XSS o 'Cross-site Scripting') en Kron Technologies Kron PAM permite XSS almacenado. Este problema afecta a Kron PAM: antes de 3.7.

Vulnerabilidad de asignación de recursos sin límites o limitación en Kron Technologies Kron PAM permite HTTP DoS. Este problema afecta a Kron PAM: antes de 3.7.

La desreferencia de puntero nulo en µD3TN a través de un identificador de endpoint de destino no singleton permite que un atacante remoto cause de manera confiable un ataque de denegación de servicio (DoS).

Se encontró una vulnerabilidad en TOTOLINK A702R 4.0.0-B20230721.1521. Se ha clasificado como crítica. Afecta una parte desconocida del archivo /boafrm/formPortFw del componente HTTP POST Request Handler. La manipulación del argumento service_type provoca un desbordamiento del búfer. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.

Se encontró una vulnerabilidad en TOTOLINK A702R 4.0.0-B20230721.1521. Se ha declarado crítica. Esta vulnerabilidad afecta al código desconocido del archivo /boafrm/formWlanMultipleAP del componente HTTP POST Request Handler. La manipulación del argumento "submit-url" provoca un desbordamiento del búfer. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.

El complemento Frontend File Manager Plugin para WordPress es vulnerable a la pérdida no autorizada de datos debido a la falta de comprobación de la función wpfm_delete_multiple_files() en todas las versiones hasta la 21.5 incluida. Esto permite que atacantes no autenticados eliminen publicaciones arbitrarias.