Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.

Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

• Vulnerabilidad en PrestaShop (CVE-2024-28390)
  Severidad: CRÍTICA
  Fecha de publicación: 14/03/2024
  Fecha de última actualización: 19/11/2025
  Un problema en el módulo de complementos avanzados ultimateimagetool para PrestaShop anterior a v.2.2.01 permite a un atacante remoto escalar privilegios y obtener información confidencial a través de un control de acceso inadecuado.
  
• Vulnerabilidad en M-Files Web (CVE-2025-3087)
  Severidad: MEDIA
  Fecha de publicación: 04/04/2025
  Fecha de última actualización: 19/11/2025
  XSS almacenado en las versiones de M-Files Web 25.1.14445.5 a 25.2.14524.4 permiten que un usuario autenticado ejecute scripts
  
• Vulnerabilidad en Absolute Persistence® (CVE-2024-6364)
  Severidad: MEDIA
  Fecha de publicación: 13/05/2025
  Fecha de última actualización: 19/11/2025
  Existe una vulnerabilidad en las versiones de Absolute Persistence® anteriores a la 2.8 cuando no está activada. Esto podría permitir que un atacante experto con acceso físico al dispositivo y control total de la red hostil inicie comandos del sistema operativo en el dispositivo. Para solucionar esta vulnerabilidad, actualice el firmware del dispositivo a la última versión disponible. Para obtener instrucciones de actualización, póngase en contacto con el fabricante del dispositivo o con Absolute Security (consulte la referencia a continuación).
  
• Vulnerabilidad en OpenSSL (CVE-2025-5480)
  Severidad: ALTA
  Fecha de publicación: 06/06/2025
  Fecha de última actualización: 19/11/2025
  Vulnerabilidad de escalada de privilegios locales en el elemento de ruta de búsqueda no controlada de Action1. Esta vulnerabilidad permite a atacantes locales escalar privilegios en las instalaciones afectadas de Action1. Para explotar esta vulnerabilidad, un atacante debe primero ejecutar código con pocos privilegios en el sistema objetivo. La falla específica se encuentra en la configuración de OpenSSL. El producto carga un archivo de configuración de OpenSSL desde una ubicación no segura. Un atacante puede aprovechar esta vulnerabilidad para escalar privilegios y ejecutar código arbitrario en el contexto de SYSTEM. Anteriormente, se denominaba ZDI-CAN-26767.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38175)
  Severidad: ALTA
  Fecha de publicación: 04/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrige otro UAF en binder_devices El commit e77aff5528a18 ("binderfs: corrige uuse-after-free en binder_devices") abordó un use-after-free donde los dispositivos podían liberarse sin eliminarse primero de la lista binder_devices. Sin embargo, hay una ruta similar en binder_free_proc() que se omitió: ====================================================================== ERROR: KASAN: slab-use-after-free in binder_remove_device+0xd4/0x100 Write of size 8 at addr ffff0000c773b900 by task umount/467 CPU: 12 UID: 0 PID: 467 Comm: umount Not tainted 6.15.0-rc7-00138-g57483a362741 #9 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_remove_device+0xd4/0x100 binderfs_evict_inode+0x230/0x2f0 evict+0x25c/0x5dc iput+0x304/0x480 dentry_unlink_inode+0x208/0x46c __dentry_kill+0x154/0x530 [...] Allocated by task 463: __kmalloc_cache_noprof+0x13c/0x324 binderfs_binder_device_create.isra.0+0x138/0xa60 binder_ctl_ioctl+0x1ac/0x230 [...] Freed by task 215: kfree+0x184/0x31c binder_proc_dec_tmpref+0x33c/0x4ac binder_deferred_func+0xc10/0x1108 process_one_work+0x520/0xba4 [...] ====================================================================== Llame a binder_remove_device() dentro de binder_free_proc() para asegurarse de que el dispositivo se elimine de la lista binder_devices antes de ser liberado.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38176)
  Severidad: ALTA
  Fecha de publicación: 04/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrección de use-after-free en binderfs_evict_inode() Al ejecutar 'stress-ng --binderfs 16 --timeout 300' bajo un kernel habilitado para KASAN, he notado lo siguiente: ERROR: KASAN: slab-use-after-free in binderfs_evict_inode+0x1de/0x2d0 Write of size 8 at addr ffff88807379bc08 by task stress-ng-binde/1699 CPU: 0 UID: 0 PID: 1699 Comm: stress-ng-binde Not tainted 6.14.0-rc7-g586de92313fc-dirty #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: dump_stack_lvl+0x1c2/0x2a0 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? __virt_addr_valid+0x18c/0x540 ? __virt_addr_valid+0x469/0x540 print_report+0x155/0x840 ? __virt_addr_valid+0x18c/0x540 ? __virt_addr_valid+0x469/0x540 ? __phys_addr+0xba/0x170 ? binderfs_evict_inode+0x1de/0x2d0 kasan_report+0x147/0x180 ? binderfs_evict_inode+0x1de/0x2d0 binderfs_evict_inode+0x1de/0x2d0 ? __pfx_binderfs_evict_inode+0x10/0x10 evict+0x524/0x9f0 ? __pfx_lock_release+0x10/0x10 ? __pfx_evict+0x10/0x10 ? do_raw_spin_unlock+0x4d/0x210 ? _raw_spin_unlock+0x28/0x50 ? iput+0x697/0x9b0 __dentry_kill+0x209/0x660 ? shrink_kill+0x8d/0x2c0 shrink_kill+0xa9/0x2c0 shrink_dentry_list+0x2e0/0x5e0 shrink_dcache_parent+0xa2/0x2c0 ? __pfx_shrink_dcache_parent+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 do_one_tree+0x23/0xe0 shrink_dcache_for_umount+0xa0/0x170 generic_shutdown_super+0x67/0x390 kill_litter_super+0x76/0xb0 binderfs_kill_super+0x44/0x90 deactivate_locked_super+0xb9/0x130 cleanup_mnt+0x422/0x4c0 ? lockdep_hardirqs_on+0x9d/0x150 task_work_run+0x1d2/0x260 ? __pfx_task_work_run+0x10/0x10 resume_user_mode_work+0x52/0x60 syscall_exit_to_user_mode+0x9a/0x120 do_syscall_64+0x103/0x210 ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0xcac57b Code: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 RSP: 002b:00007ffecf4226a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 RAX: 0000000000000000 RBX: 00007ffecf422720 RCX: 0000000000cac57b RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffecf422850 RBP: 00007ffecf422850 R08: 0000000028d06ab1 R09: 7fffffffffffffff R10: 3fffffffffffffff R11: 0000000000000246 R12: 00007ffecf422718 R13: 00007ffecf422710 R14: 00007f478f87b658 R15: 00007ffecf422830 Allocated by task 1705: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x213/0x3e0 binderfs_binder_device_create+0x183/0xa80 binder_ctl_ioctl+0x138/0x190 __x64_sys_ioctl+0x120/0x1b0 do_syscall_64+0xf6/0x210 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 1705: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x46/0x50 __kasan_slab_free+0x62/0x70 kfree+0x194/0x440 evict+0x524/0x9f0 do_unlinkat+0x390/0x5b0 __x64_sys_unlink+0x47/0x50 do_syscall_64+0xf6/0x210 entry_SYSCALL_64_after_hwframe+0x77/0x7f Esta carga de trabajo "stress-ng" provoca eliminaciones simultáneas de "binder_devices" y, por lo tanto, requiere una sincronización completa para evitar la corrupción de listas. He encontrado este problema de forma independiente, pero estoy bastante seguro de que syzbot hizo lo mismo, por lo que "Reportado por:" y "Cierra:" también deberían aplicarse en este caso.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38179)
  Severidad: ALTA
  Fecha de publicación: 04/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corregir desbordamiento de max_sge en smb_extract_folioq_to_rdma() Esto corrige el siguiente problema: [ 749.901015] [ T8673] ejecutar fstests cifs/001 a las 2025-06-17 09:40:30 [ 750.346409] [ T9870] ====================================================================== [ 750.346814] [ T9870] ERROR: KASAN: slab-out-of-bounds in smb_set_sge+0x2cc/0x3b0 [cifs] [ 750.347330] [ T9870] Write of size 8 at addr ffff888011082890 by task xfs_io/9870 [ 750.347705] [ T9870] [ 750.348077] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Not tainted 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary) [ 750.348082] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 750.348085] [ T9870] Call Trace: [ 750.348086] [ T9870] [ 750.348088] [ T9870] dump_stack_lvl+0x76/0xa0 [ 750.348106] [ T9870] print_report+0xd1/0x640 [ 750.348116] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 750.348120] [ T9870] ? kasan_complete_mode_report_info+0x26/0x210 [ 750.348124] [ T9870] kasan_report+0xe7/0x130 [ 750.348128] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs] [ 750.348262] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs] [ 750.348377] [ T9870] __asan_report_store8_noabort+0x17/0x30 [ 750.348381] [ T9870] smb_set_sge+0x2cc/0x3b0 [cifs] [ 750.348496] [ T9870] smbd_post_send_iter+0x1990/0x3070 [cifs] [ 750.348625] [ T9870] ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs] [ 750.348741] [ T9870] ? update_stack_state+0x2a0/0x670 [ 750.348749] [ T9870] ? cifs_flush+0x153/0x320 [cifs] [ 750.348870] [ T9870] ? cifs_flush+0x153/0x320 [cifs] [ 750.348990] [ T9870] ? update_stack_state+0x2a0/0x670 [ 750.348995] [ T9870] smbd_send+0x58c/0x9c0 [cifs] [ 750.349117] [ T9870] ? __pfx_smbd_send+0x10/0x10 [cifs] [ 750.349231] [ T9870] ? unwind_get_return_address+0x65/0xb0 [ 750.349235] [ T9870] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 750.349242] [ T9870] ? arch_stack_walk+0xa7/0x100 [ 750.349250] [ T9870] ? stack_trace_save+0x92/0xd0 [ 750.349254] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs] [ 750.349374] [ T9870] ? kernel_text_address+0x173/0x190 [ 750.349379] [ T9870] ? kasan_save_stack+0x39/0x70 [ 750.349382] [ T9870] ? kasan_save_track+0x18/0x70 [ 750.349385] [ T9870] ? __kasan_slab_alloc+0x9d/0xa0 [ 750.349389] [ T9870] ? __pfx___smb_send_rqst+0x10/0x10 [cifs] [ 750.349508] [ T9870] ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs] [ 750.349626] [ T9870] ? cifs_call_async+0x277/0xb00 [cifs] [ 750.349746] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs] [ 750.349867] [ T9870] ? netfs_do_issue_write+0xc2/0x340 [netfs] [ 750.349900] [ T9870] ? netfs_advance_write+0x45b/0x1270 [netfs] [ 750.349929] [ T9870] ? netfs_write_folio+0xd6c/0x1be0 [netfs] [ 750.349958] [ T9870] ? netfs_writepages+0x2e9/0xa80 [netfs] [ 750.349987] [ T9870] ? do_writepages+0x21f/0x590 [ 750.349993] [ T9870] ? filemap_fdatawrite_wbc+0xe1/0x140 [ 750.349997] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 750.350002] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs] [ 750.350131] [ T9870] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] [ 750.350255] [ T9870] ? local_clock_noinstr+0xe/0xd0 [ 750.350261] [ T9870] ? kasan_save_alloc_info+0x37/0x60 [ 750.350268] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.350271] [ T9870] ? _raw_spin_lock+0x81/0xf0 [ 750.350275] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10 [ 750.350278] [ T9870] ? smb2_setup_async_request+0x293/0x580 [cifs] [ 750.350398] [ T9870] cifs_call_async+0x477/0xb00 [cifs] [ 750.350518] [ T9870] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs] [ 750.350636] [ T9870] ? __pfx_cifs_call_async+0x10/0x10 [cifs] [ 750.350756] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10 [ 750.350760] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.350763] [ T98 ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38182)
  Severidad: ALTA
  Fecha de publicación: 04/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ublk: depurar los argumentos del espacio de usuario al agregar un dispositivo. Verificar la solidez de los valores de profundidad de cola y número de colas que obtenemos del espacio de usuario al agregar un dispositivo.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38186)
  Severidad: MEDIA
  Fecha de publicación: 04/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Se corrige la doble invocación de bnxt_ulp_stop()/bnxt_ulp_start(). Antes de la confirmación bajo la etiqueta "Correcciones", bnxt_ulp_stop() y bnxt_ulp_start() siempre se invocaban en pares. Tras dicha confirmación, se puede invocar el nuevo bnxt_ulp_restart() tras llamar a bnxt_ulp_stop(). Esto puede provocar que el método .suspend() del controlador auxiliar del controlador RoCE se invoque dos veces. La segunda llamada bnxt_re_suspend() se bloqueará cuando desreferencia un puntero NULL: (NULL ib_device): Manejar llamada de suspensión del dispositivo ERROR: kernel NULL pointer dereference, address: 0000000000000b78 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 20 UID: 0 PID: 181 Comm: kworker/u96:5 Tainted: G S 6.15.0-rc1 #4 PREEMPT(voluntary) Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 Workqueue: bnxt_pf_wq bnxt_sp_task [bnxt_en] RIP: 0010:bnxt_re_suspend+0x45/0x1f0 [bnxt_re] Code: 8b 05 a7 3c 5b f5 48 89 44 24 18 31 c0 49 8b 5c 24 08 4d 8b 2c 24 e8 ea 06 0a f4 48 c7 c6 04 60 52 c0 48 89 df e8 1b ce f9 ff <48> 8b 83 78 0b 00 00 48 8b 80 38 03 00 00 a8 40 0f 85 b5 00 00 00 RSP: 0018:ffffa2e84084fd88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffffffb4b6b934 RDI: 00000000ffffffff RBP: ffffa1760954c9c0 R08: 0000000000000000 R09: c0000000ffffdfff R10: 0000000000000001 R11: ffffa2e84084fb50 R12: ffffa176031ef070 R13: ffffa17609775000 R14: ffffa17603adc180 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa17daa397000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000b78 CR3: 00000004aaa30003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bnxt_ulp_stop+0x69/0x90 [bnxt_en] bnxt_sp_task+0x678/0x920 [bnxt_en] ? __schedule+0x514/0xf50 process_scheduled_works+0x9d/0x400 worker_thread+0x11c/0x260 ? __pfx_worker_thread+0x10/0x10 kthread+0xfe/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2b/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Compruebe el indicador BNXT_EN_FLAG_ULP_STOPPED y no continúe si ya está activado. Esto conservará las operaciones simétricas originales bnxt_ulp_stop() y bnxt_ulp_start(). Además, dentro de bnxt_ulp_start(), borre el indicador BNXT_EN_FLAG_ULP_STOPPED después de tomar el mutex para evitar cualquier condición de ejecución. Y para la simetría, solo proceda en bnxt_ulp_start() si BNXT_EN_FLAG_ULP_STOPPED está configurado.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38187)
  Severidad: ALTA
  Fecha de publicación: 04/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: se corrige un error de use-after-free en r535_gsp_rpc_push(). El contenedor RPC se libera tras pasarse a r535_gsp_rpc_send(). Al enviar el fragmento inicial de una RPC grande y pasar el contenedor RPC del emisor, este se liberará prematuramente. Por lo tanto, los intentos posteriores de enviar los fragmentos restantes resultarán en un error de use-after-free. Asigne un contenedor RPC temporal para almacenar el fragmento inicial de una RPC grande durante el envío. Libere el contenedor del emisor cuando todos los fragmentos se hayan enviado correctamente. [Rebase sobre los cambios de Blackwell. - Danilo]
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38188)
  Severidad: MEDIA
  Fecha de publicación: 04/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/a7xx: Llamada a CP_RESET_CONTEXT_STATE. Llamar a este paquete es necesario al cambiar de contexto, ya que el espacio de usuario utiliza varios fragmentos de estado para sincronizar entre BR y BV que son persistentes entre envíos, y debemos asegurarnos de que estén en un estado seguro al cambiar de contexto. De lo contrario, un envío del espacio de usuario en un contexto podría provocar que otro contexto funcione incorrectamente y se cuelgue, lo que constituye una denegación de servicio (aunque sin fugas de datos). Esto se pasó por alto durante la activación inicial de a7xx. Patchwork: https://patchwork.freedesktop.org/patch/654924/
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38189)
  Severidad: MEDIA
  Fecha de publicación: 04/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Evitar la desreferencia de puntero NULL en `v3d_job_update_stats()` El siguiente error del kernel fue informado recientemente por Mesa CI: [ 800.139824] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000588 [ 800.148619] Mem abort info: [ 800.151402] ESR = 0x0000000096000005 [ 800.155141] EC = 0x25: DABT (current EL), IL = 32 bits [ 800.160444] SET = 0, FnV = 0 [ 800.163488] EA = 0, S1PTW = 0 [ 800.166619] FSC = 0x05: level 1 translation fault [ 800.171487] Data abort info: [ 800.174357] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 800.179832] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 800.184873] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 800.190176] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001014c2000 [ 800.196607] [0000000000000588] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 800.205305] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 800.211564] Modules linked in: vc4 snd_soc_hdmi_codec drm_display_helper v3d cec gpu_sched drm_dma_helper drm_shmem_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm i2c_brcmstb snd_timer snd backlight [ 800.234448] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 800.244182] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 800.250005] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 800.256959] pc : v3d_job_update_stats+0x60/0x130 [v3d] [ 800.262112] lr : v3d_job_update_stats+0x48/0x130 [v3d] [ 800.267251] sp : ffffffc080003e60 [ 800.270555] x29: ffffffc080003e60 x28: ffffffd842784980 x27: 0224012000000000 [ 800.277687] x26: ffffffd84277f630 x25: ffffff81012fd800 x24: 0000000000000020 [ 800.284818] x23: ffffff8040238b08 x22: 0000000000000570 x21: 0000000000000158 [ 800.291948] x20: 0000000000000000 x19: ffffff8040238000 x18: 0000000000000000 [ 800.299078] x17: ffffffa8c1bd2000 x16: ffffffc080000000 x15: 0000000000000000 [ 800.306208] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 800.313338] x11: 0000000000000040 x10: 0000000000001a40 x9 : ffffffd83b39757c [ 800.320468] x8 : ffffffd842786420 x7 : 7fffffffffffffff x6 : 0000000000ef32b0 [ 800.327598] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : ffffffd842784980 [ 800.334728] x2 : 0000000000000004 x1 : 0000000000010002 x0 : 000000ba4c0ca382 [ 800.341859] Call trace: [ 800.344294] v3d_job_update_stats+0x60/0x130 [v3d] [ 800.349086] v3d_irq+0x124/0x2e0 [v3d] [ 800.352835] __handle_irq_event_percpu+0x58/0x218 [ 800.357539] handle_irq_event+0x54/0xb8 [ 800.361369] handle_fasteoi_irq+0xac/0x240 [ 800.365458] handle_irq_desc+0x48/0x68 [ 800.369200] generic_handle_domain_irq+0x24/0x38 [ 800.373810] gic_handle_irq+0x48/0xd8 [ 800.377464] call_on_irq_stack+0x24/0x58 [ 800.381379] do_interrupt_handler+0x88/0x98 [ 800.385554] el1_interrupt+0x34/0x68 [ 800.389123] el1h_64_irq_handler+0x18/0x28 [ 800.393211] el1h_64_irq+0x64/0x68 [ 800.396603] default_idle_call+0x3c/0x168 [ 800.400606] do_idle+0x1fc/0x230 [ 800.403827] cpu_startup_entry+0x40/0x50 [ 800.407742] rest_init+0xe4/0xf0 [ 800.410962] start_kernel+0x5e8/0x790 [ 800.414616] __primary_switched+0x80/0x90 [ 800.418622] Code: 8b170277 8b160296 11000421 b9000861 (b9401ac1) [ 800.424707] ---[fin del seguimiento 0000000000000000 ]--- [800.457313] ---[fin del pánico del kernel - no se sincroniza: Oops: Excepción fatal en la interrupción ]--- Este problema ocurre cuando el descriptor de archivo se cierra antes de que se completen los trabajos enviados por él. Al completarse el trabajo, actualizamos las estadísticas globales de la GPU y las estadísticas de la GPU por archivo de datos, que se exponen mediante fdinfo. Si el descriptor de archivo se cerró, la estructura `v3d_file_priv` y sus estadísticas ya se liberaron, por lo que no podemos actualizar las estadísticas por archivo de datos. Por lo tanto, si el descriptor de archivo ya se cerró, no se debe usar `--truncated---`.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38192)
  Severidad: MEDIA
  Fecha de publicación: 04/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: borrar el dst al cambiar el protocolo skb Un programa BPF NAT46 no tan cuidadoso puede hacer que el kernel se bloquee si cambia indiscriminadamente los paquetes de entrada de v4 a v6: ERROR: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) La interfaz de salida tiene un programa 4->6 conectado en la entrada. Intentamos devolver el skb de multidifusión al socket de envío. El BPF de entrada se ejecuta como parte de netif_rx(), envía un hdr v6 válido y cambia el protocolo skb a v6. Introducimos ip6_rcv_core, que intenta usar skb_dst(). Sin embargo, el dst sigue siendo IPv4 tras la salida de mcast IPv4. Borre el dst en todos los ayudantes de BPF que cambien el protocolo. Intente conservar los dst de metadatos, ya que pueden contener metadatos no relacionados con el enrutamiento.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38195)
  Severidad: MEDIA
  Fecha de publicación: 04/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Se corrige el pánico causado por NULL-PMD en huge_pte_offset() INFORMACIÓN DE ERROR: CPU 25 No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0x0 ... Seguimiento de llamadas: [<900000000023c30c>] huge_pte_offset+0x3c/0x58 [<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438 [<900000000051fee8>] __get_user_pages+0xe0/0x4c8 [<9000000000522414>] faultin_page_range+0x84/0x380 [<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48 [<900000000056689c>] do_madvise+0x1bc/0x3e8 [<9000000000566df4>] sys_madvise+0x24/0x38 [<90000000015b9e88>] do_syscall+0x78/0x98 [<9000000000221f18>] handle_syscall+0xb8/0x158 En algunos casos, pmd puede ser NULL y depender de NULL como valor de retorno para el procesamiento, por lo que es necesario determinar esta situación aquí.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38252)
  Severidad: MEDIA
  Fecha de publicación: 09/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/ras: Corregir confusión de dispositivo del controlador CPER Por inspección, cxl_cper_handle_prot_err() está haciendo una serie de suposiciones frágiles que pueden llevar a caídas: 1/ Supone que los endpoints identificados en el registro son un dispositivo CXL-type-3, nada lo garantiza. 2/ Supone que el dispositivo está enlazado al controlador cxl_pci, nada lo garantiza. 3/ Leve, mantiene el bloqueo del dispositivo sobre el seguimiento del puerto del conmutador sin ninguna razón ya que el seguimiento se genera 100% a partir de los datos en el registro. Corrija aquellos comprobando que el endpoint PCIe engendre un cxl_memdev antes de asumir el formato de los datos del controlador y mueva el bloqueo a donde se requiere. En consecuencia, esto también hace que la implementación esté lista para aceleradores CXL que no están enlazados a cxl_pci.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38253)
  Severidad: MEDIA
  Fecha de publicación: 09/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: wacom: corrección de fallo en wacom_aes_battery_handler(). El commit fd2a9b29dc9c ("HID: wacom: Eliminar la fuente de alimentación AES tras una inactividad prolongada") introdujo wacom_aes_battery_handler(), que está programado como un trabajo retrasado (aes_battery_work). En wacom_remove(), aes_battery_work no se cancela. Por lo tanto, si se retira el dispositivo mientras aes_battery_work está pendiente, se producen fallos graves o el error "Uy: fallo de protección general..." al ejecutar wacom_aes_battery_handler(). Por ejemplo, esto ocurre con dispositivos USB integrados tras la reanudación de la hibernación cuando aes_battery_work estaba pendiente en ese momento. Por lo tanto, tenga cuidado de cancelar aes_battery_work en wacom_remove().
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38254)
  Severidad: MEDIA
  Fecha de publicación: 09/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se han añadido comprobaciones de seguridad para drm_edid_raw(). Cuando se recupera el EDID mediante drm_edid_raw(), no se garantiza la devolución de los bytes de EDID correctos que el usuario solicita: puede ser nulo (lo que provoca un error) o con bytes demasiado largos que exceden el tamaño fijo de la matriz raw_edid (lo que puede provocar corrupción de memoria). Esto último se informó al conectar con un adaptador defectuoso. Se han añadido comprobaciones de seguridad para drm_edid_raw() para abordar los casos especiales mencionados y devolver EDID_BAD_INPUT en consecuencia. (Seleccionado del commit 648d3f4d209725d51900d6a3ed46b7b600140cdf)
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38255)
  Severidad: MEDIA
  Fecha de publicación: 09/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lib/group_cpus: corrección de la desreferencia de puntero NULL de group_cpus_evenly() Al probar null_blk con configfs, echo 0 > poll_queues activará el siguiente pánico: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 27 UID: 0 PID: 920 Comm: bash No contaminado 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef) Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__bitmap_or+0x48/0x70 Rastreo de llamadas: __group_cpus_evenly+0x822/0x8c0 group_cpus_evenly+0x2d9/0x490 blk_mq_map_queues+0x1e/0x110 null_map_queues+0xc9/0x170 [null_blk] blk_mq_update_queue_map+0xdb/0x160 blk_mq_update_nr_hw_queues+0x22b/0x560 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_poll_queues_store+0xa4/0x130 [null_blk] configfs_write_iter+0x109/0x1d0 vfs_write+0x26e/0x6f0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x45c4/0x45f0 do_syscall_64+0xa5/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e La causa principal es que numgrps está establecido en 0 y se devuelve ZERO_SIZE_PTR desde kcalloc(); posteriormente, se aplicará ZERO_SIZE_PTR. Solucione el problema comprobando primero numgrps en group_cpus_evenly() y devolviendo NULL directamente si numgrps es cero. [yukuai3@huawei.com: corrija también la versión sin SMP]
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38256)
  Severidad: MEDIA
  Fecha de publicación: 09/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/rsrc: se corrige la desanclaje de folio. syzbot se queja de un error de desasignación: [ 108.070381][ T14] ¡ERROR del kernel en mm/gup.c:71! [ 108.070502][ T14] Error interno: Ups - ERROR: 00000000f2000800 [#1] SMP [ 108.123672][ T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025 [ 108.127458][ T14] Workqueue: iou_exit io_ring_exit_work [ 108.174205][ T14] Call trace: [ 108.175649][ T14] sanity_check_pinned_pages+0x7cc/0x7d0 (P) [ 108.178138][ T14] unpin_user_page+0x80/0x10c [ 108.180189][ T14] io_release_ubuf+0x84/0xf8 [ 108.182196][ T14] io_free_rsrc_node+0x250/0x57c [ 108.184345][ T14] io_rsrc_data_free+0x148/0x298 [ 108.186493][ T14] io_sqe_buffers_unregister+0x84/0xa0 [ 108.188991][ T14] io_ring_ctx_free+0x48/0x480 [ 108.191057][ T14] io_ring_exit_work+0x764/0x7d8 [ 108.193207][ T14] process_one_work+0x7e8/0x155c [ 108.195431][ T14] worker_thread+0x958/0xed8 [ 108.197561][ T14] kthread+0x5fc/0x75c [ 108.199362][ T14] ret_from_fork+0x10/0x20 Podemos anclar la página final de un folio, pero entonces io_uring intentará desanclar la página principal. Si bien esto debería funcionar correctamente para mantener la página activa, los usuarios de mm indican que es incorrecto y genera una advertencia de depuración. Use unpin_user_folio() en lugar de unpin_user_page*. [axboe: adaptar al árbol actual, modificar el mensaje de confirmación]
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38258)
  Severidad: MEDIA
  Fecha de publicación: 09/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/sysfs-schemes: la liberación de la antigua ruta damon_sysfs_scheme_filter->memcg_path al escribir en memcg_path_store() asigna un búfer de memoria recién asignado a filter->memcg_path, sin liberar el búfer de memoria previamente asignado. Como resultado, los usuarios pueden perder memoria del kernel escribiendo continuamente datos en el archivo sysfs de DAMOS, memcg_path. Para solucionar la pérdida, libere el búfer de memoria previamente asignado.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38247)
  Severidad: MEDIA
  Fecha de publicación: 09/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fuga de userns y mnt_idmap en open_tree_attr(2). Una vez que want_mount_setattr() ha devuelto un resultado positivo, requiere finish_mount_kattr() para liberar ->mnt_userns. Un fallo en do_mount_setattr() no cambia esto. Como resultado, podemos acabar con fugas de userns y posiblemente también de mnt_idmap.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38248)
  Severidad: ALTA
  Fecha de publicación: 09/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bridge: mcast: Arreglar el use-after-free durante la configuración del puerto del enrutador El puente mantiene una lista global de puertos tras los cuales reside un enrutador de multidifusión. La lista se consulta durante el reenvío para garantizar que los paquetes de multidifusión se reenvíen a estos puertos incluso si los puertos no son miembros de la entrada MDB correspondiente. Cuando se habilita la vigilancia de multidifusión por VLAN, se deshabilita el contexto de multidifusión por puerto en cada puerto y el puerto se elimina de la lista global de puertos del enrutador: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev dummy1 type bridge_slave mcast_router 2 $ bridge -d mdb show | grep router router ports on br1: dummy1 # ip link set dev br1 type bridge mcast_vlan_snooping 1 $ bridge -d mdb show | grep router Sin embargo, el puerto se puede volver a agregar a la lista global incluso cuando el snooping de multidifusión por VLAN está habilitado: # ip link set dev dummy1 type bridge_slave mcast_router 0 # ip link set dev dummy1 type bridge_slave mcast_router 2 $ bridge -d mdb show | grep router router ports on br1: dummy1 Desde el commit 4b30ae9adb04 ("net: bridge: mcast: re-implement br_multicast_{enable, disabled}_port functions"), cuando el snooping de multidifusión por VLAN está habilitado, la deshabilitación de multidifusión en un puerto deshabilitará los contextos de multidifusión por {puerto, VLAN} y no el de cada puerto. Como resultado, un puerto permanecerá en la lista global de puertos del enrutador incluso después de eliminarlo. Esto generará un use-after-free [1] cuando se recorra la lista (al agregar un nuevo puerto a la lista, por ejemplo): # ip link del dev dummy1 # ip link add name dummy2 up master br1 type dummy # ip link set dev dummy2 type bridge_slave mcast_router 2 De manera similar, también se pueden encontrar entradas obsoletas en la lista de puertos del enrutador por VLAN. Cuando la vigilancia de multidifusión por VLAN está deshabilitada, los contextos por {puerto, VLAN} se deshabilitan en cada puerto y el puerto se elimina de la lista de puertos del enrutador por VLAN: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 # ip link add name dummy1 up master br1 type dummy # bridge vlan add vid 2 dev dummy1 # bridge vlan global set vid 2 dev br1 mcast_snooping 1 # bridge vlan set vid 2 dev dummy1 mcast_router 2 $ bridge vlan global show dev br1 vid 2 | grep router router ports: dummy1 # ip link set dev br1 type bridge mcast_vlan_snooping 0 $ bridge vlan global show dev br1 vid 2 | grep router Sin embargo, el puerto se puede volver a agregar a la lista por VLAN incluso cuando el snooping de multidifusión por VLAN está deshabilitado: # bridge vlan set vid 2 dev dummy1 mcast_router 0 # bridge vlan set vid 2 dev dummy1 mcast_router 2 $ bridge vlan global show dev br1 vid 2 | grep router router ports: dummy1 Cuando se elimina la VLAN del puerto, el contexto de multidifusión por {puerto, VLAN} no se deshabilitará ya que el snooping de multidifusión no está habilitado en la VLAN. Como resultado, el puerto permanecerá en la lista de puertos del enrutador por VLAN incluso después de que ya no sea miembro de la VLAN. Esto dará lugar a un use-after-free [2] cuando se recorra la lista (al añadir un nuevo puerto a la lista, por ejemplo): # ip link add name dummy2 up master br1 type dummy # bridge vlan add vid 2 dev dummy2 # bridge vlan del vid 2 dev dummy1 # bridge vlan set vid 2 dev dummy2 mcast_router 2 Solucione estos problemas eliminando el puerto de la lista de puertos del enrutador relevante (global o por VLAN) en br_multicast_port_ctx_deinit(). La función se invoca durante la eliminación del puerto con el contexto de multidifusión por puerto y durante la eliminación de VLAN con el contexto de multidifusión por {puerto, VLAN}. ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38250)
  Severidad: ALTA
  Fecha de publicación: 09/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_core: Se corrige el use-after-free en vhci_flush() syzbot informó use-after-free en vhci_flush() sin reproducción. [0] Desde el splat, un subproceso cierra() un descriptor de archivo vhci mientras su dispositivo estaba siendo usado por iotcl() en otro subproceso. Una vez que se libera el último fd refcnt, vhci_release() llama a hci_unregister_dev(), hci_free_dev() y kfree() para struct vhci_data, que está configurado en hci_dev->dev->driver_data. El problema es que no hay sincronización después de desvincular hdev de hci_dev_list en hci_unregister_dev(). Podría haber otro subproceso que aún acceda al hdev que se obtuvo antes de la operación de desvinculación. Podemos usar SRCU para dicha sincronización. Ejecutemos hci_dev_reset() en SRCU y esperemos a que se complete en hci_unregister_dev(). Otra opción sería restaurar hci_dev->destruct(), que se eliminó en el commit 587ae086f6e4 ("Bluetooth: Eliminar el bloque de comandos hci-destruct no utilizado"). Sin embargo, esta no sería una buena solución, ya que no deberíamos ejecutar hci_unregister_dev() mientras haya solicitudes ioctl() en curso, lo que podría provocar otro error de KCSAN en la ejecución de datos. Tenga en cuenta que otros controladores parecen tener el mismo problema, por ejemplo, virtbt_remove(). [0]: ERROR: KASAN: slab-use-after-free en skb_queue_empty_lockless include/linux/skbuff.h:1891 [en línea] ERROR: KASAN: slab-use-after-free en skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Lectura de tamaño 8 en la dirección ffff88807cb8d858 por la tarea syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 No contaminado 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Rastreo de llamadas: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 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 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38276)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/dax: Corrección del problema "no omitir entradas bloqueadas al escanear entradas". El commit 6be3e21d25ca ("fs/dax: no omitir entradas bloqueadas al escanear entradas") introdujo una nueva función, wait_entry_unlocked_exclusive(), que espera a que la entrada actual se desbloquee sin avanzar el estado del iterador de XArray. Esperar a que la entrada se desbloquee requiere liberar el bloqueo de XArray. Esto requiere llamar a xas_pause() antes de liberar el bloqueo, lo que deja el xas en un estado adecuado para la siguiente iteración. Sin embargo, esto tiene el efecto secundario de avanzar el estado de xas al siguiente índice. Normalmente, esto no supone un problema, ya que xas_for_each() contiene código para detectar este estado y, por lo tanto, evitar avanzar el índice una segunda vez en la siguiente iteración del bucle. No obstante, tanto los que llaman a wait_entry_unlocked_exclusive() como la propia función wait_entry_unlocked_exclusive() utilizan posteriormente el estado de xas para recargar la entrada. Como xas_pause() actualiza el estado al próximo índice, esto provocará que se omita la entrada actual que se está esperando. Esto provocó que la siguiente advertencia se disparara de forma intermitente al ejecutar xftest generic/068 en un sistema de archivos XFS con FS DAX habilitado: [ 35.067397] ------------[ cortar aquí ]------------ [ 35.068229] ADVERTENCIA: CPU: 21 PID: 1640 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xd8/0x1e0 [ 35.069717] Modules linked in: nd_pmem dax_pmem nd_btt nd_e820 libnvdimm [ 35.071006] CPU: 21 UID: 0 PID: 1640 Comm: fstest Not tainted 6.15.0-rc7+ #77 PREEMPT(voluntary) [ 35.072613] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/204 [ 35.074845] RIP: 0010:truncate_folio_batch_exceptionals+0xd8/0x1e0 [ 35.075962] Code: a1 00 00 00 f6 47 0d 20 0f 84 97 00 00 00 4c 63 e8 41 39 c4 7f 0b eb 61 49 83 c5 01 45 39 ec 7e 58 42 f68 [ 35.079522] RSP: 0018:ffffb04e426c7850 EFLAGS: 00010202 [ 35.080359] RAX: 0000000000000000 RBX: ffff9d21e3481908 RCX: ffffb04e426c77f4 [ 35.081477] RDX: ffffb04e426c79e8 RSI: ffffb04e426c79e0 RDI: ffff9d21e34816e8 [ 35.082590] RBP: ffffb04e426c79e0 R08: 0000000000000001 R09: 0000000000000003 [ 35.083733] R10: 0000000000000000 R11: 822b53c0f7a49868 R12: 000000000000001f [ 35.084850] R13: 0000000000000000 R14: ffffb04e426c78e8 R15: fffffffffffffffe [ 35.085953] FS: 00007f9134c87740(0000) GS:ffff9d22abba0000(0000) knlGS:0000000000000000 [ 35.087346] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 35.088244] CR2: 00007f9134c86000 CR3: 000000040afff000 CR4: 00000000000006f0 [ 35.089354] Call Trace: [ 35.089749] [ 35.090168] truncate_inode_pages_range+0xfc/0x4d0 [ 35.091078] truncate_pagecache+0x47/0x60 [ 35.091735] xfs_setattr_size+0xc7/0x3e0 [ 35.092648] xfs_vn_setattr+0x1ea/0x270 [ 35.093437] notify_change+0x1f4/0x510 [ 35.094219] ? do_truncate+0x97/0xe0 [ 35.094879] do_truncate+0x97/0xe0 [ 35.095640] path_openat+0xabd/0xca0 [ 35.096278] do_filp_open+0xd7/0x190 [ 35.096860] do_sys_openat2+0x8a/0xe0 [ 35.097459] __x64_sys_openat+0x6d/0xa0 [ 35.098076] do_syscall_64+0xbb/0x1d0 [ 35.098647] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 35.099444] RIP: 0033:0x7f9134d81fc1 [ 35.100033] Code: 75 57 89 f0 25 00 00 41 00 3d 00 00 41 00 74 49 80 3d 2a 26 0e 00 00 74 6d 89 da 48 89 ee bf 9c ff ff ff5 [ 35.102993] RSP: 002b:00007ffcd41e0d10 EFLAGS: 00000202 ORIG_RAX: 0000000000000101 [ 35.104263] RAX: ffffffffffffffda RBX: 0000000000000242 RCX: 00007f9134d81fc1 [ 35.105452] RDX: 0000000000000242 RSI: 00007ffcd41e1200 RDI: 00000000ffffff9c [ 35.106663] RBP: 00007ffcd41e1200 R08: 0000000000000000 R09: 0000000000000064 [ 35.107923] R10: 00000000000001a4 R11: 0000000000000202 R12: 0000000000000066 [ 35.109112] R13: 0000000000100000 R14: 0000000000100000 R15: 0000000000000400 [ 35.110357] [ 35.110769] irq event stamp: 8415587 [ 35.111486] hardirqs last enabled at (8415599): [] ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38278)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: QOS: Refactorizar la devolución de llamada TC_HTB_LEAF_DEL_LAST Este parche soluciona los siguientes problemas: 1. El tráfico activo en el nodo hoja debe detenerse antes de que su cola de envío se reasigne al padre. Este parche resuelve el problema marcando el nodo como "interno". 2. Durante un reinicio del sistema, la interfaz recibe las devoluciones de llamada TC_HTB_LEAF_DEL y TC_HTB_LEAF_DEL_LAST para eliminar sus colas HTB. En el caso de TC_HTB_LEAF_DEL_LAST, aunque la misma cola de envío se reasigne al padre, la lógica actual aún intenta actualizar el número real de colas, lo que genera las siguientes advertencias No se pueden registrar nuevas colas después de anular el registro del dispositivo. ADVERTENCIA: CPU: 0 PID: 6475 en net/core/net-sysfs.c:1714 netdev_queue_update_kobjects+0x1e4/0x200
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38281)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7996: Se ha añadido una comprobación de NULL en mt7996_thermal_init. Devm_kasprintf() puede devolver un puntero NULL en caso de error, pero este valor devuelto en mt7996_thermal_init() no se comprueba. Se ha añadido una comprobación de NULL en mt7996_thermal_init() para gestionar el error de desreferencia de puntero NULL del kernel.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38283)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hisi_acc_vfio_pci: corrección de errores en la función de migración en vivo sin controlador de dispositivo VF. Si el controlador de dispositivo VF no está cargado en el sistema operativo invitado e intentamos migrar los datos del dispositivo, la dirección de los datos migrados será nula. La operación de recuperación de la migración en vivo en el destino accederá a una dirección nula, lo que provocará errores de acceso. Por lo tanto, la migración en vivo de máquinas virtuales sin controladores de dispositivo VF añadidos no requiere la migración de datos del dispositivo. Además, si los datos de dirección de la cola obtenidos por el destino están vacíos, no se realizará el procesamiento de recuperación de la cola del dispositivo.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38284)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: pci: configurar el modo DAC manual solo mediante la API de configuración PCI. Para admitir DMA de 36 bits, configure el bit propietario del chip mediante la API de configuración PCI o la interfaz DBI del chip. Sin embargo, el mmap del dispositivo PCI aún no está configurado y el DBI tampoco es accesible mediante mmap. Por lo tanto, solo si se puede acceder al bit mediante la API de configuración PCI, el chip admite DMA de 36 bits. De lo contrario, se recurre al DMA de 32 bits. Con una dirección mmap NULL, el núcleo genera el siguiente seguimiento: ERROR: no se puede controlar el error de página para la dirección: 0000000000001090 #PF: acceso de escritura del supervisor en modo núcleo #PF: error_code(0x0002) - página no presente PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 71 Comm: irq/26-pciehp Tainted: G OE 6.14.2-061402-generic #202504101348 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE RIP: 0010:rtw89_pci_ops_write16+0x12/0x30 [rtw89_pci] RSP: 0018:ffffb0ffc0acf9d8 EFLAGS: 00010206 RAX: ffffffffc158f9c0 RBX: ffff94865e702020 RCX: 0000000000000000 RDX: 0000000000000718 RSI: 0000000000001090 RDI: ffff94865e702020 RBP: ffffb0ffc0acf9d8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000015 R13: 0000000000000719 R14: ffffb0ffc0acfa1f R15: ffffffffc1813060 FS: 0000000000000000(0000) GS:ffff9486f3480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001090 CR3: 0000000090440001 CR4: 00000000000626f0 Call Trace: rtw89_pci_read_config_byte+0x6d/0x120 [rtw89_pci] rtw89_pci_cfg_dac+0x5b/0xb0 [rtw89_pci] rtw89_pci_probe+0xa96/0xbd0 [rtw89_pci] ? __pfx___device_attach_driver+0x10/0x10 ? __pfx___device_attach_driver+0x10/0x10 local_pci_probe+0x47/0xa0 pci_call_probe+0x5d/0x190 pci_device_probe+0xa7/0x160 really_probe+0xf9/0x370 ? pm_runtime_barrier+0x55/0xa0 __driver_probe_device+0x8c/0x140 driver_probe_device+0x24/0xd0 __device_attach_driver+0xcd/0x170 bus_for_each_drv+0x99/0x100 __device_attach+0xb4/0x1d0 device_attach+0x10/0x20 pci_bus_add_device+0x59/0x90 pci_bus_add_devices+0x31/0x80 pciehp_configure_device+0xaa/0x170 pciehp_enable_slot+0xd6/0x240 pciehp_handle_presence_or_link_change+0xf1/0x180 pciehp_ist+0x162/0x1c0 irq_thread_fn+0x24/0x70 irq_thread+0xef/0x1c0 ? __pfx_irq_thread_fn+0x10/0x10 ? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0xfc/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x47/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38287)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/cm: Se omite la aserción de lockdep y la advertencia al liberar un mensaje antiguo. El controlador de finalización de envío puede ejecutarse después de que cm_id haya avanzado a otro mensaje. El bloqueo de cm_id no es necesario en este caso, pero un cambio reciente reutilizó cm_free_priv_msg(), que confirma que el bloqueo se mantiene y emite una advertencia si el mensaje pendiente de cm_id es diferente del que se está liberando.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38290)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: corrección de corrupción de nodos en la lista ar->arvifs. En el flujo de código de recuperación de WLAN actual, ath12k_core_halt() solo reinicializa la cabecera de lista "arvifs". Esto provocará que el nodo de lista inmediatamente posterior a la cabecera de lista se convierta en un nodo de lista inválido. Esto se debe a que el nodo anterior de ese nodo aún apunta a la cabecera de lista "arvifs", pero el siguiente ya no apunta a ese nodo. Cuando se produce una recuperación de WLAN durante la ejecución de una eliminación de vif, y esto ocurre antes de spin_lock_bh(&ar->data_lock) en ath12k_mac_vdev_delete(), list_del() detectará la situación mencionada anteriormente, lo que activará un pánico del kernel. La solución consiste en eliminar y reinicializar todos los nodos de lista vif de la cabecera de lista "arvifs" durante la detención de WLAN. La reinicialización valida los nodos de la lista, garantizando así que list_del() en ath12k_mac_vdev_delete() pueda ejecutarse correctamente. Rastreo de llamadas: __list_del_entry_valid_or_report+0xd4/0x100 (P) ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k] ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k] cfg80211_wiphy_work+0xfc/0x100 process_one_work+0x164/0x2d0 worker_thread+0x254/0x380 kthread+0xfc/0x100 ret_from_fork+0x10/0x20 The change is mostly copied from the ath11k patch: https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38291)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Evitar el envío de comandos WMI al firmware durante un fallo del firmware Actualmente, encontramos el siguiente seguimiento de llamadas al kernel cuando se produce un fallo del firmware. Esto sucede porque el host envía comandos WMI al firmware mientras está en recuperación, lo que provoca que los comandos fallen y resulte en el seguimiento de llamadas al kernel. Establezca los indicadores ATH12K_FLAG_CRASH_FLUSH y ATH12K_FLAG_RECOVERY cuando el controlador del host reciba la notificación de fallo del firmware de MHI. Esto evita el envío de comandos WMI al firmware durante la recuperación. Seguimiento de llamadas: dump_stack_lvl+0x75/0xc0 register_lock_class+0x6be/0x7a0 ? __lock_acquire+0x644/0x19a0 __lock_acquire+0x95/0x19a0 lock_acquire+0x265/0x310 ? ath12k_ce_send+0xa2/0x210 [ath12k] ? find_held_lock+0x34/0xa0 ? ath12k_ce_send+0x56/0x210 [ath12k] _raw_spin_lock_bh+0x33/0x70 ? ath12k_ce_send+0xa2/0x210 [ath12k] ath12k_ce_send+0xa2/0x210 [ath12k] ath12k_htc_send+0x178/0x390 [ath12k] ath12k_wmi_cmd_send_nowait+0x76/0xa0 [ath12k] ath12k_wmi_cmd_send+0x62/0x190 [ath12k] ath12k_wmi_pdev_bss_chan_info_request+0x62/0xc0 [ath1 ath12k_mac_op_get_survey+0x2be/0x310 [ath12k] ieee80211_dump_survey+0x99/0x240 [mac80211] nl80211_dump_survey+0xe7/0x470 [cfg80211] ? kmalloc_reserve+0x59/0xf0 genl_dumpit+0x24/0x70 netlink_dump+0x177/0x360 __netlink_dump_start+0x206/0x280 genl_family_rcv_msg_dumpit.isra.22+0x8a/0xe0 ? genl_family_rcv_msg_attrs_parse.isra.23+0xe0/0xe0 ? genl_op_lock.part.12+0x10/0x10 ? genl_dumpit+0x70/0x70 genl_rcv_msg+0x1d0/0x290 ? nl80211_del_station+0x330/0x330 [cfg80211] ? genl_get_cmd_both+0x50/0x50 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x1f/0x30 netlink_unicast+0x1b6/0x260 netlink_sendmsg+0x31a/0x450 __sock_sendmsg+0xa8/0xb0 ____sys_sendmsg+0x1e4/0x260 ___sys_sendmsg+0x89/0xe0 ? local_clock_noinstr+0xb/0xc0 ? rcu_is_watching+0xd/0x40 ? kfree+0x1de/0x370 ? __sys_sendmsg+0x7a/0xc0 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38292)
  Severidad: ALTA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: se corrige el acceso no válido a la memoria. En ath12k_dp_rx_msdu_coalesce(), rxcb se obtiene de skb y el booleano is_continuation forma parte de rxcb. Actualmente, tras liberar skb, se accede de nuevo a rxcb->is_continuation, lo cual es incorrecto, ya que la memoria ya está liberada. Esto podría provocar un error de uso tras liberación. Por lo tanto, se debe corregir definiendo localmente el booleano is_continuation desde rxcb, de modo que, tras liberar skb, se pueda usar is_continuation. Solo se ha probado la compilación.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38294)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: corrección del acceso nulo en el controlador de contexto de asignación de canal. Actualmente, cuando ath12k_mac_assign_vif_to_vdev() falla, se accede al controlador de radio (ar) desde el controlador VIF del enlace (arvif) para el registro de depuración. Esto es incorrecto. En el escenario de fallo, el controlador de radio es nulo. Corrija el acceso nulo y evite el acceso al controlador de radio migrando a la función auxiliar de registro de depuración de hardware (ath12k_hw_warn). Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38296)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: platform_profile: Evitar la inicialización en plataformas sin ACPI. El controlador de perfil de plataforma se carga incluso en plataformas que no tienen ACPI habilitado. La inicialización de las entradas sysfs se trasladó recientemente de platform_profile_register() a la llamada init del módulo, y estas entradas requieren la inicialización de acpi_kobj, lo cual no ocurre cuando ACPI está deshabilitado. Esto genera la siguiente advertencia: ADVERTENCIA: CPU: 5 PID: 1 en fs/sysfs/group.c:131 internal_create_group+0xa22/0xdd8 Módulos vinculados: CPU: 5 UID: 0 PID: 1 Comm: swapper/0 Contaminado: GW 6.15.0-rc7-dirty #6 PREEMPT Contaminado: [W]=WARN Nombre del hardware: riscv-virtio,qemu (DT) epc : internal_create_group+0xa22/0xdd8 ra : internal_create_group+0xa22/0xdd8 Rastreo de llamadas: internal_create_group+0xa22/0xdd8 sysfs_create_group+0x22/0x2e platform_profile_init+0x74/0xb2 do_one_initcall+0x198/0xa9e kernel_init_freeable+0x6d8/0x780 kernel_init+0x28/0x24c ret_from_fork+0xe/0x18 Solucione esto comprobando si ACPI está habilitado antes de intentar crear entradas sysfs. [ rjw: Ediciones de asunto y registro de cambios ]
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38297)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: EM: Se corrige un posible error de división por cero en em_compute_costs(). Cuando el dispositivo no es de tipo CPU, table[i].performance no se inicializa en la función em_init_performance() anterior, lo que resulta en una división por cero al calcular los costos en em_compute_costs(). Dado que el algoritmo "cost" solo se utiliza para cálculos de eficiencia energética de EAS y actualmente no lo utilizan otros controladores de dispositivos, se debe agregar la comprobación _is_cpu_device(dev) para evitar este problema de división por cero.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38299)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: mt8195: Establecer ETDM1/2 IN/OUT como COMP_DUMMY(). ETDM2_IN_BE y ETDM1_OUT_BE se definen como COMP_EMPTY(); en ese caso, el códec dai_name será nulo. Se evita un bloqueo si el árbol de dispositivos no asigna un códec a estos enlaces. [ 1.179936] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000000 [ 1.181065] Mem abort info: [ 1.181420] ESR = 0x0000000096000004 [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.182576] SET = 0, FnV = 0 [ 1.182964] EA = 0, S1PTW = 0 [ 1.183367] FSC = 0x04: level 0 translation fault [ 1.183983] Data abort info: [ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.186439] [0000000000000000] user address but active_mm is swapper [ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1.188029] Modules linked in: [ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85 [ 1.189515] Hardware name: Radxa NIO 12L (DT) [ 1.190065] Workqueue: events_unbound deferred_probe_work_func [ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.191683] pc : __pi_strcmp+0x24/0x140 [ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0 [ 1.192854] sp : ffff800083473970 [ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002 [ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88 [ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8 [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff [ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006 [ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374 [ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018 [ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 [ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d [ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000 [ 1.202236] Call trace: [ 1.202545] __pi_strcmp+0x24/0x140 (P) [ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8 [ 1.203644] platform_probe+0x70/0xe8 [ 1.204106] really_probe+0xc8/0x3a0 [ 1.204556] __driver_probe_device+0x84/0x160 [ 1.205104] driver_probe_device+0x44/0x130 [ 1.205630] __device_attach_driver+0xc4/0x170 [ 1.206189] bus_for_each_drv+0x8c/0xf8 [ 1.206672] __device_attach+0xa8/0x1c8 [ 1.207155] device_initial_probe+0x1c/0x30 [ 1.207681] bus_probe_device+0xb0/0xc0 [ 1.208165] deferred_probe_work_func+0xa4/0x100 [ 1.208747] process_one_work+0x158/0x3e0 [ 1.209254] worker_thread+0x2c4/0x3e8 [ 1.209727] kthread+0x134/0x1f0 [ 1.210136] ret_from_fork+0x10/0x20 [ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402) [ 1.211355] ---[ fin de seguimiento 0000000000000000 ]---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38301)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmem: zynqmp_nvmem: unbreak driver after cleanup El commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") cambió el controlador para esperar que el puntero del dispositivo se pase como "contexto", pero en nvmem el parámetro de contexto proviene de nvmem_config.priv que nunca se establece, lo que genera excepciones de puntero nulo cuando se accede al dispositivo.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38302)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: no usar submit_bio_noacct_nocheck en blk_zone_wplug_bio_work. Las BIOS en cola en el complemento de escritura de zona ya han pasado por toda la preparación en la ruta submit_bio, incluida la protección contra congelamiento. Enviarlas mediante submit_bio_noacct_nocheck duplica el trabajo y puede causar interbloqueos al congelar una cola con complementos de escritura de BIOS pendientes. Vaya directamente a ->submit_bio o blk_mq_submit_bio para omitir la protección contra congelamiento y las comprobaciones adicionales innecesarias.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38303)
  Severidad: MEDIA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: eir: Se solucionan posibles fallos en eir_create_adv_data eir_create_adv_data puede intentar agregar EIR_FLAGS y EIR_TX_POWER sin verificar si encajan.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38289)
  Severidad: ALTA
  Fecha de publicación: 10/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Evitar un posible use-after-free de ndlp en dev_loss_tmo_callbk. Smatch detectó un posible use-after-free de un objeto ndlp en dev_loss_tmo_callbk durante la descarga del controlador o la gestión de errores fatales. Se solucionó reordenando el código para evitar un posible use-after-free si se eliminó previamente la referencia inicial a la lista de nodos.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38367)
  Severidad: ALTA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: KVM: Evitar el desbordamiento con el índice de la matriz. La variable índice se modifica y se reutiliza como índice de la matriz al modificar el registro EIOINTC_ENABLE. Se producirá un problema de desbordamiento del índice de la matriz.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38368)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: tps6594-pfsm: Se ha añadido una comprobación de puntero nulo en tps6594_pfsm_probe(). El valor devuelto, pfsm->miscdev.name, desde devm_kasprintf() podría ser nulo. Se ha añadido una comprobación de puntero para evitar posibles desreferencias de punteros nulos. Esto es similar a la corrección en el commit 3027e7b15b02 ("ice: Se corrigen algunos problemas de desreferencia de puntero nulo en ice_ptp.c"). Nuestra herramienta de análisis estático ha detectado este problema.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38373)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/mlx5: Arreglar un posible bloqueo en la anulación del registro de MR El problema surge cuando se invoca kzalloc() mientras se mantiene umem_mutex o cualquier otro bloqueo adquirido bajo umem_mutex. Esto es problemático porque kzalloc() puede activar fs_reclaim_aqcuire(), que puede, a su vez, invocar mmu_notifier_invalidate_range_start(). Esta función puede llevar a mlx5_ib_invalidate_range(), que intenta adquirir umem_mutex de nuevo, lo que resulta en un bloqueo. El flujo problemático: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | ? revoke_mr() | ? mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | ? mutex_lock(&dev->cache.rb_lock) | ? mlx5r_cache_create_ent_locked() | ? kzalloc(GFP_KERNEL) | ? fs_reclaim() | ? mmu_notifier_invalidate_range_start() | ? mlx5_ib_invalidate_range() | ? mutex_lock(&umem_odp->umem_mutex) ? cache_ent_find_and_store() | ? mutex_lock(&dev->cache.rb_lock) | Además, cuando se llama a kzalloc() desde dentro de cache_ent_find_and_store(), encontramos el mismo bloqueo debido a la readquisición de umem_mutex. Se resuelve liberando umem_mutex en dereg_mr() después de umr_revoke_mr() y antes de adquirir rb_lock. Esto garantiza que no se mantenga umem_mutex mientras se realizan asignaciones de memoria que podrían activar la ruta de recuperación. Este cambio previene el interbloqueo al asegurar el orden correcto de los bloqueos y evitar mantenerlos durante las operaciones de asignación de memoria que podrían activar la ruta de recuperación. La siguiente advertencia de lockdep demuestra el bloqueo: ython3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib] but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es:-> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138 -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core] ---truncated---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38374)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: optee: ffa: corrección de suspensión en contexto atómico. El controlador OP-TEE registra la función notif_callback() para las notificaciones FF-A. Sin embargo, esta función se llama en un contexto atómico, lo que genera errores como este al procesar notificaciones asíncronas: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0-00019-g657536ebe0aa #13 | Hardware name: linux,dummy-virt (DT) | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | optee_get_msg_arg+0x7c/0x21c | simple_call_with_arg+0x50/0xc0 | optee_do_bottom_half+0x14/0x20 | notif_callback+0x3c/0x48 | handle_notif_callbacks+0x9c/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 Solucione esto agregando una cola de trabajo para procesar la notificación en un contexto no atómico.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38376)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: chipidea: udc: desconectar/reconectar del host al suspender/reanudar Shawn y John informaron de un problema de cuelgue durante la suspensión del sistema como se muestra a continuación: - El dispositivo USB está habilitado como Ethernet - Hay transferencia de datos a través de USB Ethernet (scp un archivo grande entre el host y el dispositivo) - El dispositivo entra/sale de suspensión (echo mem > /sys/power/state) La causa raíz es que el controlador del dispositivo USB está suspendido, pero el bus USB sigue activo, lo que provocó que el host USB siguiera transfiriendo datos con el dispositivo y el dispositivo siguiera poniendo en cola las solicitudes USB (en este caso, un paquete TCP ACK retrasado desencadenó el problema) después de que el controlador se suspendiera; sin embargo, el reloj del controlador USB ya estaba desactivado. Entonces, si el acceso al controlador udc se registra después de ese punto, el sistema se colgará. La forma correcta de evitar este problema es desconectar el dispositivo del host cuando el bus USB no esté en estado de suspensión. Entonces, el host recibirá el evento de desconexión y detendrá la transferencia de datos a tiempo. Para que el dispositivo USB siga funcionando después de reanudar el sistema, esto volverá a conectar el dispositivo automáticamente. Para que la activación USB funcione si el bus USB ya está en estado de suspensión, esto mantendrá la conexión solo cuando el controlador del dispositivo USB haya habilitado la capacidad de activación.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38378)
  Severidad: ALTA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: appletb-kbd: corrección de use-after-free de slab en appletb_kbd_probe. En la sonda appletb_kbd_probe(), se asigna una estructura "struct appletb_kbd *kbd" mediante devm_kzalloc() para almacenar datos relacionados con el teclado de la barra táctil. Posteriormente, si backlight_device_get_by_name() encuentra un dispositivo de retroiluminación con el nombre "appletb_backlight", se configura un temporizador (kbd->inactivity_timer) con appletb_inactivity_timer() y se arma para que se ejecute después de appletb_tb_dim_timeout (60) segundos. Se activa un uso tras liberación cuando se produce un fallo después de que el temporizador esté armado. Esto, en última instancia, significa que se produce un fallo en la sonda y, como resultado, se libera la estructura "struct appletb_kbd *kbd", que es la memoria administrada por el dispositivo. Después de 60 segundos, el temporizador habrá expirado y __run_timers intentará acceder al temporizador (kbd->inactivity_timer); sin embargo, la estructura kdb se habrá liberado, lo que provocará un use-after-free. [ 71.636938] ================================================================== [ 71.637915] BUG: KASAN: slab-use-after-free in __run_timers+0x7ad/0x890 [ 71.637915] Write of size 8 at addr ffff8881178c5958 by task swapper/1/0 [ 71.637915] [ 71.637915] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.16.0-rc2-00318-g739a6c93cc75-dirty #12 PREEMPT(voluntary) [ 71.637915] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 71.637915] Call Trace: [ 71.637915] [ 71.637915] dump_stack_lvl+0x53/0x70 [ 71.637915] print_report+0xce/0x670 [ 71.637915] ? __run_timers+0x7ad/0x890 [ 71.637915] kasan_report+0xce/0x100 [ 71.637915] ? __run_timers+0x7ad/0x890 [ 71.637915] __run_timers+0x7ad/0x890 [ 71.637915] ? __pfx___run_timers+0x10/0x10 [ 71.637915] ? update_process_times+0xfc/0x190 [ 71.637915] ? __pfx_update_process_times+0x10/0x10 [ 71.637915] ? _raw_spin_lock_irq+0x80/0xe0 [ 71.637915] ? _raw_spin_lock_irq+0x80/0xe0 [ 71.637915] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 71.637915] run_timer_softirq+0x141/0x240 [ 71.637915] ? __pfx_run_timer_softirq+0x10/0x10 [ 71.637915] ? __pfx___hrtimer_run_queues+0x10/0x10 [ 71.637915] ? kvm_clock_get_cycles+0x18/0x30 [ 71.637915] ? ktime_get+0x60/0x140 [ 71.637915] handle_softirqs+0x1b8/0x5c0 [ 71.637915] ? __pfx_handle_softirqs+0x10/0x10 [ 71.637915] irq_exit_rcu+0xaf/0xe0 [ 71.637915] sysvec_apic_timer_interrupt+0x6c/0x80 [ 71.637915] [ 71.637915] [ 71.637915] Allocated by task 39: [ 71.637915] kasan_save_stack+0x33/0x60 [ 71.637915] kasan_save_track+0x14/0x30 [ 71.637915] __kasan_kmalloc+0x8f/0xa0 [ 71.637915] __kmalloc_node_track_caller_noprof+0x195/0x420 [ 71.637915] devm_kmalloc+0x74/0x1e0 [ 71.637915] appletb_kbd_probe+0x37/0x3c0 [ 71.637915] hid_device_probe+0x2d1/0x680 [ 71.637915] really_probe+0x1c3/0x690 [ 71.637915] __driver_probe_device+0x247/0x300 [ 71.637915] driver_probe_device+0x49/0x210 [...] [ 71.637915] [ 71.637915] Freed by task 39: [ 71.637915] kasan_save_stack+0x33/0x60 [ 71.637915] kasan_save_track+0x14/0x30 [ 71.637915] kasan_save_free_info+0x3b/0x60 [ 71.637915] __kasan_slab_free+0x37/0x50 [ 71.637915] kfree+0xcf/0x360 [ 71.637915] devres_release_group+0x1f8/0x3c0 [ 71.637915] hid_device_probe+0x315/0x680 [ 71.637915] really_probe+0x1c3/0x690 [ 71.637915] __driver_probe_device+0x247/0x300 [ 71.637915] driver_probe_device+0x49/0x210 [...] La causa principal del problema es que el temporizador no se desactiva en rutas de fallo, lo que provoca que permanezca activo y acceda a la memoria liberada. Para solucionar esto, llame a timer_delete_sync() para desactivarlo. Otro pequeño problema es que timer_delete_sync se llama incondicionalmente en appletb_kbd_remove(). Para solucionarlo, compruebe si hay un `kbd->backlight_dev` válido antes de llamar a timer_delete_sync.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38379)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: se corrige la advertencia al reconectar el canal. Al reconectar un canal en smb2_reconnect_server(), se pasa una transacción ficticia a smb2_reconnect() con ->query_interface sin inicializar, por lo que no se puede ejecutar queue_delayed_work() en ella. Corrija la siguiente advertencia asegurándose de que se esté poniendo en cola el trabajador retrasado desde la transacción correcta. WARNING: CPU: 4 PID: 1126 at kernel/workqueue.c:2498 __queue_delayed_work+0x1d2/0x200 Modules linked in: cifs cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs] CPU: 4 UID: 0 PID: 1126 Comm: kworker/4:0 Not tainted 6.16.0-rc3 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-4.fc42 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__queue_delayed_work+0x1d2/0x200 Code: 41 5e 41 5f e9 7f ee ff ff 90 0f 0b 90 e9 5d ff ff ff bf 02 00 00 00 e8 6c f3 07 00 89 c3 eb bd 90 0f 0b 90 e9 57 f> 0b 90 e9 65 fe ff ff 90 0f 0b 90 e9 72 fe ff ff 90 0f 0b 90 e9 RSP: 0018:ffffc900014afad8 EFLAGS: 00010003 RAX: 0000000000000000 RBX: ffff888124d99988 RCX: ffffffff81399cc1 RDX: dffffc0000000000 RSI: ffff888114326e00 RDI: ffff888124d999f0 RBP: 000000000000ea60 R08: 0000000000000001 R09: ffffed10249b3331 R10: ffff888124d9998f R11: 0000000000000004 R12: 0000000000000040 R13: ffff888114326e00 R14: ffff888124d999d8 R15: ffff888114939020 FS: 0000000000000000(0000) GS:ffff88829f7fe000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe7a2b4038 CR3: 0000000120a6f000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: queue_delayed_work_on+0xb4/0xc0 smb2_reconnect+0xb22/0xf50 [cifs] smb2_reconnect_server+0x413/0xd40 [cifs] ? __pfx_smb2_reconnect_server+0x10/0x10 [cifs] ? local_clock_noinstr+0xd/0xd0 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 process_one_work+0x4c5/0xa10 ? __pfx_process_one_work+0x10/0x10 ? __list_add_valid_or_report+0x37/0x120 worker_thread+0x2f1/0x5a0 ? __kthread_parkme+0xde/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? __pfx_kthread+0x10/0x10 ? local_clock_noinstr+0xd/0xd0 ? ret_from_fork+0x1b/0x1f0 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 ? rcu_is_watching+0x20/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x15b/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 irq event stamp: 1116206 hardirqs last enabled at (1116205): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1116206): [] queue_delayed_work_on+0x6e/0xc0 softirqs last enabled at (1116138): [] __smb_send_rqst+0x42d/0x950 [cifs] softirqs last disabled at (1116136): [] release_sock+0x21/0xf0
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38381)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: cs40l50-vibra - Se corrige una posible desreferencia de NULL en cs40l50_upload_owt(). La función cs40l50_upload_owt() asigna memoria mediante kmalloc() sin comprobar si hay fallos de asignación, lo que podría provocar una desreferencia de puntero NULL. Devuelve -ENOMEM en caso de fallo de asignación.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38383)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmalloc: corrección de la ejecución de datos en show_numa_info() Se encontró la siguiente ejecución de datos en show_numa_info(): ================================================================== BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show read to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 .... write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 .... value changed: 0x0000008f -> 0x00000000 ================================================================== Según este informe, existe una competencia de lectura/escritura de datos porque m->private es accesible a varias CPU. Para solucionar esto, en lugar de asignar el montón en proc_vmalloc_init() y pasar la dirección del montón a m->private, vmalloc_info_show() debería asignarlo.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38388)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_ffa: Reemplazar mutex por rwlock para evitar la suspensión en contexto atómico El uso actual de un mutex para proteger los accesos a la tabla hash del notificador puede provocar problemas en el contexto atómico. Esto da como resultado las siguientes advertencias del kernel: | BUG: función de suspensión llamada desde un contexto no válido en kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest Depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 No contaminado 6.14.0 #4 | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Rastreo de llamadas: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | handle_notif_callbacks+0x54/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | work_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 Para solucionar esto, reemplace el mutex con un rwlock para proteger los accesos a la tabla hash del notificador. Esto garantiza que el bloqueo del lado de lectura no se suspenda y que varios lectores puedan adquirir el bloqueo simultáneamente, evitando contenciones innecesarias y posibles interbloqueos. El acceso de escritura se mantiene exclusivo, preservando la corrección. Este cambio resuelve las advertencias de lockdep sobre la posible suspensión en un contexto atómico.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38390)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_ffa: Corregir fuga de memoria liberando el nodo de devolución de llamada del notificador. El commit e0573444edbf ("firmware: arm_ffa: Añadir interfaces para solicitar devoluciones de llamada de notificación") añade compatibilidad con devoluciones de llamada de notificador mediante la asignación e inserción de un nodo de devolución de llamada en una tabla hash durante el registro de notificadores. Sin embargo, al anular el registro, el código solo elimina el nodo de la tabla hash sin liberar la memoria asociada, lo que provoca una fuga de memoria. Para resolver el problema de fuga de memoria, asegúrese de que el nodo de devolución de llamada del notificador asignado se libere correctamente tras eliminarlo de la entrada de la tabla hash.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38392)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: convertir mutex de cola de control en un spinlock Con VIRTCHNL2_CAP_MACFILTER habilitado, se genera la siguiente advertencia al cargar el módulo: [ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578 [ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager [ 324.701689] preempt_count: 201, expected: 0 [ 324.701693] RCU nest depth: 0, expected: 0 [ 324.701697] 2 locks held by NetworkManager/1582: [ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0 [ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870 [ 324.701749] Preemption disabled at: [ 324.701752] [] __dev_open+0x3dd/0x870 [ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary) [ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022 [ 324.701774] Call Trace: [ 324.701777] [ 324.701779] dump_stack_lvl+0x5d/0x80 [ 324.701788] ? __dev_open+0x3dd/0x870 [ 324.701793] __might_resched.cold+0x1ef/0x23d <..> [ 324.701818] __mutex_lock+0x113/0x1b80 <..> [ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf] [ 324.701935] ? kasan_save_track+0x14/0x30 [ 324.701941] idpf_mb_clean+0x143/0x380 [idpf] <..> [ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf] [ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf] [ 324.702021] ? rcu_is_watching+0x12/0xc0 [ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf] <..> [ 324.702122] __hw_addr_sync_dev+0x1cf/0x300 [ 324.702126] ? find_held_lock+0x32/0x90 [ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf] [ 324.702152] __dev_open+0x3f8/0x870 [ 324.702159] ? __pfx___dev_open+0x10/0x10 [ 324.702174] __dev_change_flags+0x443/0x650 <..> [ 324.702208] netif_change_flags+0x80/0x160 [ 324.702218] do_setlink.isra.0+0x16a0/0x3960 <..> [ 324.702349] rtnl_newlink+0x12fd/0x21e0 The sequence is as follows: rtnl_newlink()-> __dev_change_flags()-> __dev_open()-> dev_set_rx_mode() - > # disables BH and grabs "dev->addr_list_lock" idpf_set_rx_mode() -> # proceed only if VIRTCHNL2_CAP_MACFILTER is ON __dev_uc_sync() -> idpf_add_mac_filter -> idpf_add_del_mac_filters -> idpf_send_mb_msg() -> idpf_mb_clean() -> idpf_ctlq_clean_sq() # mutex_lock(cq_lock) Se corrige convirtiendo cq_lock en un bloqueo de giro. Todas las operaciones bajo el nuevo bloqueo son seguras, excepto la liberación de memoria DMA, que puede usar vunmap(). Se corrige solicitando una memoria física contigua para la asignación de DMA.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38394)
  Severidad: ALTA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: appletb-kbd: corrige la corrupción de memoria de input_handler_list En appletb_kbd_probe se inicializa un manejador de entrada y luego se registra con el núcleo de entrada a través de input_register_handler(). Cuando esto sucede, el núcleo de entrada agregará el manejador de entrada (específicamente su nodo) a la input_handler_list global. La input_handler_list es central para la funcionalidad del núcleo de entrada y se recorre en varios lugares del núcleo de entrada. Un ejemplo de esto es cuando se conecta un nuevo dispositivo de entrada y se registra con el núcleo de entrada. El input_handler en la sonda se asigna como memoria administrada por el dispositivo. Si ocurre un fallo de la sonda después de input_register_handler(), la memoria del input_handler se libera, pero permanecerá en la input_handler_list. Esto significa efectivamente que la input_handler_list contiene un puntero colgante a los datos que pertenecen a un manejador de entrada liberado. Esto causa un problema al conectar cualquier otro dispositivo de entrada. En mi caso, tenía un ratón óptico USB PixArt HP antiguo y decidí conectarlo tras un fallo después de la función input_register_handler(). Esto provocó el registro de este dispositivo de entrada mediante input_register_device, lo que implica recorrer cada controlador de la lista de controladores de entrada corrupta y llamar a input_attach_handler(), lo que permite a cada controlador vincularse al nuevo dispositivo registrado. El problema principal es un UAF que causa corrupción de memoria en la lista de controladores de entrada. Para solucionarlo, debemos asegurarnos de que el controlador de entrada no esté registrado en el núcleo de entrada. Esto se realiza mediante input_unregister_handler(). [ 63.191597] ================================================================== [ 63.192094] BUG: KASAN: slab-use-after-free in input_attach_handler.isra.0+0x1a9/0x1e0 [ 63.192094] Read of size 8 at addr ffff888105ea7c80 by task kworker/0:2/54 [ 63.192094] [ 63.192094] CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.16.0-rc2-00321-g2aa6621d [ 63.192094] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.164 [ 63.192094] Workqueue: usb_hub_wq hub_event [ 63.192094] Call Trace: [ 63.192094] [ 63.192094] dump_stack_lvl+0x53/0x70 [ 63.192094] print_report+0xce/0x670 [ 63.192094] kasan_report+0xce/0x100 [ 63.192094] input_attach_handler.isra.0+0x1a9/0x1e0 [ 63.192094] input_register_device+0x76c/0xd00 [ 63.192094] hidinput_connect+0x686d/0xad60 [ 63.192094] hid_connect+0xf20/0x1b10 [ 63.192094] hid_hw_start+0x83/0x100 [ 63.192094] hid_device_probe+0x2d1/0x680 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [ 63.192094] bus_for_each_drv+0x10f/0x190 [ 63.192094] __device_attach+0x18e/0x370 [ 63.192094] bus_probe_device+0x123/0x170 [ 63.192094] device_add+0xd4d/0x1460 [ 63.192094] hid_add_device+0x30b/0x910 [ 63.192094] usbhid_probe+0x920/0xe00 [ 63.192094] usb_probe_interface+0x363/0x9a0 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 [ 63.192094] __device_attach_driver+0x160/0x320 [ 63.192094] bus_for_each_drv+0x10f/0x190 [ 63.192094] __device_attach+0x18e/0x370 [ 63.192094] bus_probe_device+0x123/0x170 [ 63.192094] device_add+0xd4d/0x1460 [ 63.192094] usb_set_configuration+0xd14/0x1880 [ 63.192094] usb_generic_driver_probe+0x78/0xb0 [ 63.192094] usb_probe_device+0xaa/0x2e0 [ 63.192094] really_probe+0x1c3/0x690 [ 63.192094] __driver_probe_device+0x247/0x300 [ 63.192094] driver_probe_device+0x49/0x210 ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38397)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  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---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38398)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  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.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38402)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: devolver un tamaño 0 para la clave RSS si no se admite. Devolver -EOPNOTSUPP desde una función que devuelve u32 provoca una conversión y, como resultado, un valor de tamaño no válido. Usar -EOPNOTSUPP como tamaño probablemente provocará un error de asignación. Comando: ethtool -x eth0. Es visible en todos los dispositivos que no tienen configurados los límites RSS. [ 136.615917] Call Trace: [ 136.615921] [ 136.615927] ? __warn+0x89/0x130 [ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330 [ 136.615953] ? report_bug+0x164/0x190 [ 136.615968] ? handle_bug+0x58/0x90 [ 136.615979] ? exc_invalid_op+0x17/0x70 [ 136.615987] ? asm_exc_invalid_op+0x1a/0x20 [ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330 [ 136.616028] __alloc_pages_noprof+0xe/0x20 [ 136.616038] ___kmalloc_large_node+0x80/0x110 [ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0 [ 136.616081] __kmalloc_noprof+0x32c/0x4c0 [ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616114] ethnl_default_doit+0x107/0x3d0 [ 136.616131] genl_family_rcv_msg_doit+0x100/0x160 [ 136.616147] genl_rcv_msg+0x1b8/0x2c0 [ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10 [ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10 [ 136.616176] netlink_rcv_skb+0x58/0x110 [ 136.616186] genl_rcv+0x28/0x40 [ 136.616195] netlink_unicast+0x19b/0x290 [ 136.616206] netlink_sendmsg+0x222/0x490 [ 136.616215] __sys_sendto+0x1fd/0x210 [ 136.616233] __x64_sys_sendto+0x24/0x30 [ 136.616242] do_syscall_64+0x82/0x160 [ 136.616252] ? __sys_recvmsg+0x83/0xe0 [ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210 [ 136.616275] ? do_syscall_64+0x8e/0x160 [ 136.616282] ? __count_memcg_events+0xa1/0x130 [ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30 [ 136.616306] ? handle_mm_fault+0xae/0x2d0 [ 136.616319] ? do_user_addr_fault+0x379/0x670 [ 136.616328] ? clear_bhb_loop+0x45/0xa0 [ 136.616340] ? clear_bhb_loop+0x45/0xa0 [ 136.616349] ? clear_bhb_loop+0x45/0xa0 [ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 136.616369] RIP: 0033:0x7fd30ba7b047 [ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44 [ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047 [ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003 [ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c [ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340 [ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38405)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: se corrige una fuga de memoria de la integridad de la bio. Si nvmet recibe comandos con metadatos, se produce una fuga de memoria continua de la slab kmalloc-128 o, más precisamente, bio->bi_integrity. Desde el commit bf4c89fc8797 ("bloqueo: no llamar a bio_uninit desde bio_endio"), cada usuario de bio_init debe usar también bio_uninit. De lo contrario, la integridad de la bio no se libera. nvmet usa bio_init para la bios en línea. Desinicie la bios en línea para completar la desasignación de la integridad en la bio.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38407)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: cpu_ops_sbi: Usar una matriz estática para boot_data. Desde el commit 6b9f29b81b15 ("riscv: Habilitar el asignador de primer fragmento de página pcpu"), si NUMA está habilitado, el asignador de páginas por CPU puede usarse en configuraciones muy dispersas o cuando se solicita al arrancar con percpu_alloc=page. En ese caso, los datos por CPU se colocan en el área vmalloc. Sin embargo, sbi_hsm_hart_start() necesita la dirección física de sbi_hart_boot_data y simplemente asume que __pa() funcionaría. Esto provoca que el hart recién iniciado acceda inmediatamente a una dirección no válida y se cuelgue. Afortunadamente, la estructura sbi_hart_boot_data no es demasiado grande, por lo que podemos asignar una matriz estáticamente para boot_data, colocándola en la imagen del kernel. Esto soluciona el problema del arranque SMP con NUMA=y en Sophgo SG2042. Para reproducir en QEMU: Establezca CONFIG_NUMA=y y CONFIG_DEBUG_VIRTUAL=y, luego ejecute con: qemu-system-riscv64 -M virt -smp 2 -nographic \ -kernel arch/riscv/boot/Image \ -append "percpu_alloc=page" Salida del kernel: [ 0.000000] Booting Linux on hartid 0 [ 0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025 ... [ 0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712 ... [ 0.083192] smp: Bringing up secondary CPUs ... [ 0.086722] ------------[ cut here ]------------ [ 0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080) [ 0.088001] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:14 __virt_to_phys+0xae/0xe8 [ 0.088376] Modules linked in: [ 0.088656] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc1 #11 NONE [ 0.088833] Hardware name: riscv-virtio,qemu (DT) [ 0.088948] epc : __virt_to_phys+0xae/0xe8 [ 0.089001] ra : __virt_to_phys+0xae/0xe8 [ 0.089037] epc : ffffffff80021eaa ra : ffffffff80021eaa sp : ff2000000004bbc0 [ 0.089057] gp : ffffffff817f49c0 tp : ff60000001d60000 t0 : 5f6f745f74726976 [ 0.089076] t1 : 0000000000000076 t2 : 705f6f745f747269 s0 : ff2000000004bbe0 [ 0.089095] s1 : ff2000000001d080 a0 : 0000000000000000 a1 : 0000000000000000 [ 0.089113] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.089131] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000 [ 0.089155] s2 : ffffffff8130dc00 s3 : 0000000000000001 s4 : 0000000000000001 [ 0.089174] s5 : ffffffff8185eff8 s6 : ff2000007f1eb000 s7 : ffffffff8002a2ec [ 0.089193] s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000000 [ 0.089211] s11: 0000000000000000 t3 : ffffffff8180a9f7 t4 : ffffffff8180a9f7 [ 0.089960] t5 : ffffffff8180a9f8 t6 : ff2000000004b9d8 [ 0.089984] status: 0000000200000120 badaddr: ffffffff80021eaa cause: 0000000000000003 [ 0.090101] [] __virt_to_phys+0xae/0xe8 [ 0.090228] [] sbi_cpu_start+0x6e/0xe8 [ 0.090247] [] __cpu_up+0x1e/0x8c [ 0.090260] [] bringup_cpu+0x42/0x258 [ 0.090277] [] cpuhp_invoke_callback+0xe0/0x40c [ 0.090292] [] __cpuhp_invoke_callback_range+0x68/0xfc [ 0.090320] [] _cpu_up+0x11a/0x244 [ 0.090334] [] cpu_up+0x52/0x90 [ 0.090384] [] bringup_nonboot_cpus+0x78/0x118 [ 0.090411] [] smp_init+0x34/0xb8 [ 0.090425] [] kernel_init_freeable+0x148/0x2e4 [ 0.090442] [] kernel_init+0x1e/0x14c [ 0.090455] [] ret_from_fork_kernel+0xe/0xf0 [ 0.090471] [] ret_from_fork_kernel_asm+0x16/0x18 [ 0.090560] ---[ end trace 0000000000000000 ]--- [ 1.179875] CPU1: failed to come online [ 1.190324] smp: Brought up 1 node, 1 CPU
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38408)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: genirq/irq_sim: Inicializar correctamente los punteros del contexto de trabajo. Inicializar correctamente los punteros del miembro `ops` usando kzalloc() en lugar de kmalloc() al asignar el contexto de trabajo de simulación. De lo contrario, los punteros contienen contenido aleatorio, lo que provoca una desreferenciación no válida.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38411)
  Severidad: ALTA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Corregir doble put de solicitud Si una solicitud netfs finaliza durante el bucle de pausa, tendrá la referencia que pertenece al indicador IN_PROGRESS eliminada en ese punto; sin embargo, si luego va al bucle de espera final, eso *también* pondrá la referencia porque ve que el indicador IN_PROGRESS está limpio y asume incorrectamente que esto sucedió cuando llamó al recopilador. De hecho, como IN_PROGRESS está limpio, no deberíamos volver a llamar al recopilador ya que ha hecho toda la limpieza, como llamar a ->ki_complete(). Corrija esto haciendo que netfs_collect_in_app() simplemente regrese, lo que indica que hemos terminado si se elimina IN_PROGRESS.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38413)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-net: xsk: rx: corrección de la comprobación de la longitud del marco. Al llamar a buf_to_xdp, el argumento len es la longitud de los datos del marco sin la longitud del encabezado de Virtio (vi->hdr_len). Comprobamos esta longitud con xsk_pool_get_rx_frame_size() + vi->hdr_len para garantizar que la longitud proporcionada no supere el tamaño del fragmento asignado. El valor adicional de vi->hdr_len se debe a que, en virtnet_add_recvbuf_xsk, usamos parte de XDP_PACKET_HEADROOM para el encabezado de virtio y solicitamos al vhost que comience a colocar datos desde hard_start + XDP_PACKET_HEADROOM - vi->hdr_len, no hard_start + XDP_PACKET_HEADROOM. Sin embargo, el primer búfer tiene virtio_header, por lo que la longitud máxima del fotograma en el primer búfer solo puede ser xsk_pool_get_rx_frame_size(), no xsk_pool_get_rx_frame_size() + vi->hdr_len, como en la comprobación actual. Este commit añade un argumento adicional a buf_to_xdp para diferenciar entre el primer búfer y los demás y calcular correctamente la longitud máxima del fotograma.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38414)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: corrección de la definición de GCC_GCC_PCIE_HOT_RST para WCN7850. GCC_GCC_PCIE_HOT_RST está mal definido para WCN7850, lo que provoca un fallo del kernel en algunas plataformas específicas. Dado que este registro es divergente para WCN7850 y QCN9274, muévalo a la tabla de registros para permitir definiciones diferentes. A continuación, corrija la dirección del registro de WCN7850 para solucionar este problema. Nota: IPQ5332 no se ve afectado, ya que no es un dispositivo basado en PCIe. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38417)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: se corrige la fuga de memoria del código de eswitch en el escenario de reinicio. Se añade un verificador simple del modo eswitch al procedimiento de conexión de VF y se asignan las estructuras de memoria requeridas para el representante de puerto solo en el modo switchdev. Los flujos de reinicio activan el procedimiento de desconexión/conexión de VF (si está presente). Podría implicar la recreación del/de los representante(s) de puerto de VF si el dispositivo está configurado en modo switchdev (no en el modo heredado). La memoria se asignaba ciegamente en la implementación actual, independientemente del modo, y no se liberaba en el modo heredado. Rastreo de Kmemeleak: objeto sin referencia (percpu) 0x7e3bce5b888458 (size 40): comm "bash", pid 1784, jiffies 4295743894 hex dump (first 32 bytes on cpu 45): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): pcpu_alloc_noprof+0x4c4/0x7c0 ice_repr_create+0x66/0x130 [ice] ice_repr_create_vf+0x22/0x70 [ice] ice_eswitch_attach_vf+0x1b/0xa0 [ice] ice_reset_all_vfs+0x1dd/0x2f0 [ice] ice_pci_err_resume+0x3b/0xb0 [ice] pci_reset_function+0x8f/0x120 reset_store+0x56/0xa0 kernfs_fop_write_iter+0x120/0x1b0 vfs_write+0x31c/0x430 ksys_write+0x61/0xd0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Testing hints (ethX is PF netdev): - create at least one VF echo 1 > /sys/class/net/ethX/device/sriov_numvfs - trigger the reset echo 1 > /sys/class/net/ethX/device/reset
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38421)
  Severidad: ALTA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86/amd: pmf: Usar asignaciones administradas por dispositivo. Si la configuración de Smart PC falla por cualquier motivo, esto puede provocar una doble liberación al descargar amd-pmf. Esto se debe a que dev->buf se liberó, pero nunca se configuró como NULL y se libera de nuevo en amd_pmf_remove(). Para evitar errores sutiles de asignación en fallos que provoquen una doble liberación, cambie todas las asignaciones a asignaciones administradas por dispositivo.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38423)
  Severidad: ALTA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: codecs: wcd9375: Se corrige la doble liberación de los suministros del regulador. El controlador obtiene los suministros del regulador en la ruta de la sonda con devm_regulator_bulk_get(), por lo que no debería llamar a regulator_bulk_free() por error y eliminar las rutas para evitar la doble liberación.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38426)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: Se ha añadido validación básica para el encabezado RAS. Si el encabezado RAS leído desde la EEPROM está dañado, podría intentar asignar una gran cantidad de memoria para leer los registros. Se ha añadido validación a los campos del encabezado.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38427)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: screen_info: Reubicar framebuffers detrás de puentes PCI. Aplicar desplazamientos de ventana del puente host PCI a los framebuffers de screen_info. Corrige el acceso no válido a la memoria de E/S. Los recursos detrás de un puente host PCI se pueden reubicar mediante un desplazamiento determinado en el rango de direcciones de CPU del kernel utilizado para E/S. El rango de memoria del framebuffer almacenado en screen_info se refiere a las direcciones de CPU tal como se ven durante el arranque (donde el desplazamiento es 0). Durante el arranque, el firmware puede asignar un desplazamiento de memoria diferente al puente host PCI y, por lo tanto, reubicar la dirección del framebuffer del dispositivo gráfico PCI tal como lo ve el kernel. La información en screen_info también debe actualizarse. El asistente pcibios_bus_to_resource() realiza la reubicación del recurso framebuffer de screen_info (indicado en direcciones de bus PCI). El resultado coincide con el recurso de memoria de E/S del dispositivo gráfico PCI (indicado en direcciones de CPU). Como antes, almacenamos la información necesaria para actualizarla posteriormente en screen_info. El commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers" agregó el código para actualizar screen_info. Se basa en una funcionalidad similar a la que ya existía en efifb. Efifb usa un puntero al recurso PCI, mientras que el código más reciente realiza un memcpy de la región. Por lo tanto, efifb detecta cualquier actualización del recurso PCI y evita el problema. v3: - Usar struct pci_bus_region solo para direcciones de bus PCI (Bjorn) - Aclarar la semántica de las direcciones en los mensajes y comentarios de la confirmación (Bjorn) v2: - Etiquetas corregidas (Takashi, Ivan) - Información actualizada sobre efifb
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38429)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: ep: Actualizar el puntero de lectura solo después de escribir en el búfer. Dentro de mhi_ep_ring_add_element, el puntero de lectura (rd_offset) se actualiza antes de escribir en el búfer, lo que podría causar condiciones de ejecución donde el host ve un puntero de lectura actualizado antes de que se escriba en el búfer. Actualizar rd_offset prematuramente puede provocar que el host acceda a un elemento no inicializado o incompleto, lo que resulta en corrupción de datos. Invoque la escritura en el búfer antes de actualizar rd_offset para garantizar que el elemento esté completamente escrito antes de indicar su disponibilidad.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38431)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corregir regresión con enlaces simbólicos SMB nativos. Algunos usuarios y clientes informaron que sus herramientas de copia de seguridad/copia comenzaban a fallar cuando el directorio copiado contenía enlaces simbólicos que el cliente no podía analizar, incluso si no se seguían. Para solucionar esto, permita que lstat(2) y readlink(2) funcionen correctamente incluso cuando el cliente no pueda resolver el enlace simbólico, restaurando así el comportamiento anterior.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38432)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: netpoll: Inicializar el campo de suma de comprobación UDP antes del commit de suma de comprobación f1fce08e63fe ("netpoll: Eliminar la asignación redundante") eliminó la inicialización de la suma de comprobación UDP, lo cual era incorrecto y rompió la transmisión IPv6 de netpoll debido a una suma de comprobación incorrecta. udph->check debe configurarse antes de llamar a csum_ipv6_magic().
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38433)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: se corrige el soporte de constantes de tiempo de ejecución para kernels nommu la función `__runtime_fixup_32` no maneja el caso donde `val` es cero correctamente (como podría ocurrir al parchar un kernel nommu y hacer referencia a una dirección física por debajo del límite de 4GiB cuyos 32 bits superiores son todos cero) porque nada en la lógica existente evita que el código tome la rama `else` de ambos nop-checks y emita dos instrucciones `nop`. Esto deja basura aleatoria en el registro que se supone que recibe los 32 bits superiores del puntero en lugar de cero que, cuando se combina con el valor de los 32 bits inferiores, produce un puntero no válido y causa un pánico del kernel cuando finalmente se accede a ese puntero. El autor consideró claramente que si la instrucción `lui` se convierte en `nop`, la segunda instrucción debe ajustarse para que se convierta en `li` en lugar de `addi`, introduciendo así la variable `addi_insn_mask`. Sin embargo, no siguió esta lógica completamente hasta el caso en que se ejecuta la rama `else`. Para solucionarlo, simplemente ajuste la lógica para garantizar que la segunda rama `else` no se ejecute si la primera instrucción se convierte en `nop`.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38434)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "riscv: Define TASK_SIZE_MAX for __access_ok()". Esto revierte el commit ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for __access_ok()"). Este commit cambia TASK_SIZE_MAX a LONG_MAX para optimizar access_ok(), ya que el valor predeterminado de TASK_SIZE_MAX (predeterminado) requiere cálculos. El razonamiento era que todas las direcciones de usuario son menores que LONG_MAX y todas las direcciones de kernel son mayores que LONG_MAX. Por lo tanto, access_ok() puede filtrar direcciones de kernel. Las direcciones entre TASK_SIZE y LONG_MAX no son direcciones de usuario válidas, pero access_ok() las deja pasar. Se consideró que esto era correcto, ya que no son direcciones válidas a nivel de hardware. Desafortunadamente, se omite un caso: get_user_pages_fast() acepta direcciones entre TASK_SIZE y LONG_MAX. futex(), por ejemplo, usa get_user_pages_fast(). Esto causa el problema reportado por Robert [1]. Por lo tanto, revierte este commit . TASK_SIZE_MAX se cambia al valor predeterminado: TASK_SIZE. Lamentablemente, esto reduce el rendimiento, ya que TASK_SIZE es más costoso de calcular que LONG_MAX. Pero primero la corrección; podemos pensar en la optimización más adelante, si es necesario.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38435)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: vector: Se corrige el guardado/restauración de contexto con xtheadvector. Anteriormente, solo se guardaban/restauraban correctamente las versiones v0 a v7, y el contexto de las versiones v8 a v31 estaba dañado. Guarde/restaure correctamente las versiones v8 a v31 para evitar la interrupción del espacio de usuario.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38436)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/scheduler: señal de valla programada al finalizar un trabajo. Cuando se finaliza una entidad de la aplicación B, drm_sched_entity_kill() elimina todos los trabajos pertenecientes a esa entidad mediante drm_sched_entity_kill_jobs_work(). Si el trabajo de la aplicación A depende de una valla programada del trabajo de la aplicación B, y dicha valla no se señaliza correctamente durante el proceso de finalización, no se puede eliminar la dependencia de la aplicación A. Esto provoca que la aplicación A se cuelgue indefinidamente mientras espera una dependencia que nunca se resolverá. Solucione este problema asegurándose de que las vallas programadas se señalicen correctamente cuando se finaliza una entidad, lo que permite que las aplicaciones dependientes continúen su ejecución.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38438)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: hda: Usar devm_kstrdup() para evitar fugas de memoria. La dirección de sof_pdata->tplg_filename puede ser asignada por kstrdup() y puede sobrescribirse. Se detectó una fuga de memoria con kmemleak:unreferenced object 0xffff88812391ff60 (size 16): comm "kworker/4:1", pid 161, jiffies 4294802931 hex dump (first 16 bytes): 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic. backtrace (crc 4bf1675c): __kmalloc_node_track_caller_noprof+0x49c/0x6b0 kstrdup+0x46/0xc0 hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic] sof_init_environment+0x16f/0xb50 [snd_sof] sof_probe_continue+0x45/0x7c0 [snd_sof] sof_probe_work+0x1e/0x40 [snd_sof] process_one_work+0x894/0x14b0 worker_thread+0x5e5/0xfb0 kthread+0x39d/0x760 ret_from_fork+0x31/0x70 ret_from_fork_asm+0x1a/0x30
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38440)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Se corrige la competencia entre la desactivación de DIM y net_dim(). Existe una competencia entre la desactivación de las devoluciones de llamada de DIM y NAPI mediante el puntero dim en el RQ o SQ. Si NAPI comprueba el bit de estado de DIM y lo ve aún establecido, asume que `rq->dim` o `sq->dim` son válidos. Sin embargo, si DIM se desactiva justo después de dicha comprobación, es posible que el puntero ya esté establecido en NULL, lo que provoca una desreferencia de puntero NULL en net_dim(). Para solucionar esto, llame a `synchronize_net()` antes de liberar el contexto de DIM. Esto garantiza que todas las devoluciones de llamada de NAPI en curso finalicen antes de que se borre el puntero. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:net_dim+0x23/0x190 ... Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? common_interrupt+0xf/0xa0 ? sysvec_call_function_single+0xb/0x90 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? net_dim+0x23/0x190 ? mlx5e_poll_ico_cq+0x41/0x6f0 [mlx5_core] ? sysvec_apic_timer_interrupt+0xb/0x90 mlx5e_handle_rx_dim+0x92/0xd0 [mlx5_core] mlx5e_napi_poll+0x2cd/0xac0 [mlx5_core] ? mlx5e_poll_ico_cq+0xe5/0x6f0 [mlx5_core] busy_poll_stop+0xa2/0x200 ? mlx5e_napi_poll+0x1d9/0xac0 [mlx5_core] ? mlx5e_trigger_irq+0x130/0x130 [mlx5_core] __napi_busy_loop+0x345/0x3b0 ? sysvec_call_function_single+0xb/0x90 ? asm_sysvec_call_function_single+0x16/0x20 ? sysvec_apic_timer_interrupt+0xb/0x90 ? pcpu_free_area+0x1e4/0x2e0 napi_busy_loop+0x11/0x20 xsk_recvmsg+0x10c/0x130 sock_recvmsg+0x44/0x70 __sys_recvfrom+0xbc/0x130 ? __schedule+0x398/0x890 __x64_sys_recvfrom+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ... ---[ end trace 0000000000000000 ]--- ... ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38442)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: rechazar dispositivos de bloque bs > ps cuando THP está deshabilitado Si THP está deshabilitado y cuando hay un dispositivo de bloque con un tamaño de bloque lógico > tamaño de página, se produce el siguiente pánico de desreferencia de ptr nulo durante el arranque:[ [13.2 mK AOSAN: null-ptr-deref in range [0x0000000000000000-0x0000000000K0 0 0[07] [ 13.017749] RIP: 0010:create_empty_buffers+0x3b/0x380 [ 13.025448] Call Trace: [ 13.025692] [ 13.025895] block_read_full_folio+0x610/0x780 [ 13.026379] ? __pfx_blkdev_get_block+0x10/0x10 [ 13.027008] ? __folio_batch_add_and_move+0x1fa/0x2b0 [ 13.027548] ? __pfx_blkdev_read_folio+0x10/0x10 [ 13.028080] filemap_read_folio+0x9b/0x200 [ 13.028526] ? __pfx_filemap_read_folio+0x10/0x10 [ 13.029030] ? __filemap_get_folio+0x43/0x620 [ 13.029497] do_read_cache_folio+0x155/0x3b0 [ 13.029962] ? __pfx_blkdev_read_folio+0x10/0x10 [ 13.030381] read_part_sector+0xb7/0x2a0 [ 13.030805] read_lba+0x174/0x2c0 [ 13.045348] nvme_scan_ns+0x684/0x850 [nvme_core] [ 13.045858] ? __pfx_nvme_scan_ns+0x10/0x10 [nvme_core] [ 13.046414] ? _raw_spin_unlock+0x15/0x40 [ 13.046843] ? __switch_to+0x523/0x10a0 [ 13.047253] ? kvm_clock_get_cycles+0x14/0x30 [ 13.047742] ? __pfx_nvme_scan_ns_async+0x10/0x10 [nvme_core] [ 13.048353] async_run_entry_fn+0x96/0x4f0 [ 13.048787] process_one_work+0x667/0x10a0 [ 13.049219] worker_thread+0x63c/0xf60 Como la compatibilidad con folios grandes depende de THP, solo se permiten dispositivos de bloque bs > ps si THP está habilitado.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38446)
  Severidad: ALTA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: imx: Se corrige un acceso fuera de los límites en dispmix_csr_clk_dev_data. Cuando num_parents es 4, __clk_register() genera un acceso fuera de los límites al acceder al miembro parent_names. Use ARRAY_SIZE() en lugar de codificar el número. BUG: KASAN: global-out-of-bounds in __clk_register+0x1844/0x20d8 Read of size 8 at addr ffff800086988e78 by task kworker/u24:3/59 Hardware name: NXP i.MX95 19X19 board (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x8c/0xcc print_report+0x398/0x5fc kasan_report+0xd4/0x114 __asan_report_load8_noabort+0x20/0x2c __clk_register+0x1844/0x20d8 clk_hw_register+0x44/0x110 __clk_hw_register_mux+0x284/0x3a8 imx95_bc_probe+0x4f4/0xa70
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38447)
  Severidad: ALTA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/rmap: corrige el posible acceso fuera de los límites de la tabla de páginas durante la desasignación por lotes Como señaló David[1], la lógica de desasignación por lotes en try_to_unmap_one() puede leer más allá del final de una tabla PTE cuando las asignaciones PTE de un folio grande no están completamente contenidas dentro de una sola tabla de páginas. Si bien este escenario puede ser poco común, un problema desencadenable desde el espacio de usuario debe corregirse independientemente de su probabilidad. Este parche corrige el acceso fuera de los límites refactorizando la lógica en un nuevo ayudante, folio_unmap_pte_batch(). El nuevo ayudante calcula correctamente el tamaño de lote seguro al limitar el escaneo en los límites de VMA y PMD. Para simplificar el código, también admite el procesamiento por lotes parcial (es decir, cualquier número de páginas desde 1 hasta el máximo seguro calculado), ya que no hay una razón sólida para un caso especial de folios completamente mapeados.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38449)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/gem: Adquisición de referencias en manejadores GEM para framebuffers. Un manejador GEM puede liberarse mientras el objeto de búfer GEM está asociado a un framebuffer DRM. Esto provoca la liberación del dma-buf que respalda el objeto de búfer, si lo hay. [1] Intentar usar el framebuffer en otras operaciones de configuración de modo provoca un fallo de segmentación. Esto ocurre con mayor frecuencia con controladores que utilizan planos de sombra para vmapear el dma-buf durante un cambio de página. A continuación se muestra un ejemplo. [ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]--- Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references. Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before. v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38450)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7925: evitar la desreferencia de puntero nulo en mt7925_sta_set_decap_offload(). Se ha añadido una comprobación nula para msta->vif antes de acceder a sus miembros para evitar un pánico del kernel en la implementación en modo AP. Esto también soluciona el problema reportado en [1]. El fallo se produce cuando esta función se activa antes de que la estación se inicialice por completo. El seguimiento de llamadas muestra un fallo de página en mt7925_sta_set_decap_offload() debido al acceso a recursos cuando msta->vif es nulo. Para solucionar esto, se añade un retorno anticipado si msta->vif es nulo y se comprueba que wcid.sta esté listo. Esto garantiza que solo procedamos con la configuración de descarga de decap cuando el estado de la estación se inicialice correctamente. [14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0 [14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G [14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE [14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) [14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] [14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common] [14739.851985] sp : ffffffc085efb500 [14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158 [14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001 [14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88 [14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000 [14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080 [14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000 [14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0 [14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100 [14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000 [14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8 [14739.926686] Call trace: [14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] [14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211] [14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211] [14739.946860] sta_info_move_state+0x1c/0x30 [mac80211] [14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211] [14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211] [14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211] [14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211] [14739.975516] genl_family_rcv_msg_doit+0xdc/0x150 [14739.980158] genl_rcv_msg+0x218/0x298 [14739.983830] netlink_rcv_skb+0x64/0x138 [14739.987670] genl_rcv+0x40/0x60 [14739.990816] netlink_unicast+0x314/0x380 [14739.994742] netlink_sendmsg+0x198/0x3f0 [14739.998664] __sock_sendmsg+0x64/0xc0 [14740.002324] ____sys_sendmsg+0x260/0x298 [14740.006242] ___sys_sendmsg+0xb4/0x110
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38452)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: rtsn: Se corrige una desreferencia de puntero nulo en rtsn_probe(). Se agrega una verificación para el valor de retorno de rcar_gen4_ptp_alloc() para evitar una posible desreferencia de puntero nulo.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38453)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/msg_ring: garantizar que la liberación de io_kiocb se posponga para RCU syzbot informa que agregar defer/local task_work mediante msg_ring puede afectar a una solicitud que se ha liberado: CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 No contaminado 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Rastreo de llamadas: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 io_req_local_work_add io_uring/io_uring.c:1184 [inline] __io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252 io_msg_remote_post io_uring/msg_ring.c:103 [inline] io_msg_data_remote io_uring/msg_ring.c:133 [inline] __io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151 io_msg_ring_data io_uring/msg_ring.c:173 [inline] io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314 __io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739 io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762 io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874 io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642 io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 que se supone que es seguro con la asignación de solicitudes. Sin embargo, las solicitudes del anillo msg asignan y liberan por sí solas, por lo que deben posponer la liberación hasta un momento razonable. Agregue un rcu_head y use kfree_rcu() en ambos puntos donde se liberan las solicitudes. Solo el de io_msg_tw_complete() es estrictamente obligatorio, ya que ha sido visible en el otro anillo, pero úselo consistentemente también en el otro punto. Esto no debería causar otros problemas, aparte de las quejas legítimas de KASAN.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38454)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: ad1816a: Se corrige la posible desreferencia de puntero NULL en snd_card_ad1816a_pnp(). Utilice pr_warn() en lugar de dev_warn() cuando 'pdev' sea NULL para evitar una posible desreferencia de puntero NULL.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38463)
  Severidad: MEDIA
  Fecha de publicación: 25/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: Correcto signado en el cálculo del espacio restante de skb Syzkaller informó de un error [1] en el que sk->sk_forward_alloc puede desbordarse. Al enviar datos, si existe un skb al final de la cola de escritura, el kernel intentará añadir los nuevos datos a ese skb. Sin embargo, el código que comprueba el espacio disponible en el skb presenta un fallo: ''' copy = size_goal - skb->len ''' Los tipos de las variables implicadas son: ''' copy: ssize_t (s64 en sistemas de 64 bits) size_goal: int skb->len: unsigned int ''' Debido a las reglas de promoción de tipos de C, el signed size_goal se convierte en un unsigned int para que coincida con skb->len antes de la resta. El resultado es un unsigned int. Cuando este resultado entero sin signo se asigna a la variable de copia s64, se extiende a cero, conservando su valor no negativo. Por lo tanto, la copia siempre es >= 0. Supongamos que enviamos 2 GB de datos y que size_goal se ha ajustado a un valor menor que skb->len. La resta hará que la copia contenga un entero positivo muy grande. En la lógica subsiguiente, este valor alto se utiliza para actualizar sk->sk_forward_alloc, lo que puede provocar fácilmente un desbordamiento. El reproductor syzkaller utiliza TCP_REPAIR para crear esta condición de forma fiable. Sin embargo, esto también puede ocurrir en situaciones reales. La función tcp_bound_to_half_wnd() también puede reducir size_goal a un valor pequeño. Esto provocaría que la función tcp_wmem_schedule() posterior estableciera sk->sk_forward_alloc en un valor cercano a INT_MAX. Las solicitudes de asignación de memoria adicionales harían que sk_forward_alloc se repita y se vuelva negativo. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38469)
  Severidad: MEDIA
  Fecha de publicación: 28/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/xen: Se corrige la lógica de limpieza en la emulación de las hiperllamadas de sondeo schedop de Xen. kvm_xen_schedop_poll ejecuta kmalloc_array() cuando una máquina virtual sondea el host en busca de más de un canal de eventos potr (nr_ports > 1). Después de kmalloc_array(), las rutas de error deben pasar por la etiqueta "out", pero la llamada a kvm_read_guest_virt() no. [Mensaje de confirmación ajustado. - Paolo]
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38475)
  Severidad: MEDIA
  Fecha de publicación: 28/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smc: Se corrigen varios errores debido a la confusión de tipos inet_sock. syzbot reportó símbolos extraños [0][1] en cipso_v4_sock_setattr() al liberar inet_sk(sk)->inet_opt. La dirección se liberó varias veces a pesar de ser memoria de solo lectura. cipso_v4_sock_setattr() no causó ningún error, y la causa raíz fue la confusión de tipos. La confirmación citada permitió crear smc_sock como un socket INET. El problema es que struct smc_sock no tiene struct inet_sock como primer miembro, sino que secuestra AF_INET y AF_INET6 sk_family, lo que confunde varias ubicaciones. En este caso, inet_sock.inet_opt era en realidad smc_sock.clcsk_data_ready(), que es una dirección de una función en el segmento de texto. $ pahole -C inet_sock vmlinux struct inet_sock { ... struct ip_options_rcu * inet_opt; /* 784 8 */ $ pahole -C smc_sock vmlinux struct smc_sock { ... void (*clcsk_data_ready)(struct sock *); /* 784 8 */ The same issue for another field was reported before. [2][3] At that time, an ugly hack was suggested [4], but it makes both INET and SMC code error-prone and hard to change. Also, yet another variant was fixed by a hacky commit 98d4435efcbf3 ("net/smc: prevent NULL pointer dereference in txopt_get"). Instead of papering over the root cause by such hacks, we should not allow non-INET socket to reuse the INET infra. Let's add inet_sock as the first member of smc_sock. [0]: kvfree_call_rcu(): Double-freed call. rcu_head 000000006921da73 WARNING: CPU: 0 PID: 6718 at mm/slab_common.c:1956 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 Modules linked in: CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 lr : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 sp : ffff8000a03a7730 x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3 x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00 x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0 x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000 x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360 x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000 Call trace: kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 (P) cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914 netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581 smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912 security_inode_setsecurity+0x118/0x3c0 security/security.c:2706 __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251 __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295 vfs_setxattr+0x158/0x2ac fs/xattr.c:321 do_setxattr fs/xattr.c:636 [inline] file_setxattr+0x1b8/0x294 fs/xattr.c:646 path_setxattrat+0x2ac/0x320 fs/xattr.c:711 __do_sys_fsetxattr fs/xattr.c:761 [inline] __se_sys_fsetxattr fs/xattr.c:758 [inline] __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 [ ---truncated---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38484)
  Severidad: ALTA
  Fecha de publicación: 28/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: backend: corrección de escritura fuera de límite. El búfer está configurado a 80 caracteres. Si quien llama escribe más caracteres, count se trunca al espacio máximo disponible en "simple_write_to_buffer". Posteriormente, se escribe un terminador de cadena en el búfer en el desplazamiento count sin verificación de los límites. La terminación cero se escribe OUT-OF-BOUND. Para evitarlo, se debe añadir una verificación de que el búfer dado sea menor que el búfer.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38486)
  Severidad: MEDIA
  Fecha de publicación: 28/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soundwire: Revertir "soundwire: qcom: Añadir compatibilidad con la API set_channel_map". Esto revierte el commit 7796c97df6b1b2206681a07f3c80f6023a6593d5. Este parche interrumpió la versión Dragonboard 845c (sdm845). Veo: Excepción BRK de kernel inesperada en EL1 Error interno: BRK handler: 00000000f20003e8 [#1] SMP pc : qcom_swrm_set_channel_map+0x7c/0x80 [soundwire_qcom] lr : snd_soc_dai_set_channel_map+0x34/0x78 Call trace: qcom_swrm_set_channel_map+0x7c/0x80 [soundwire_qcom] (P) sdm845_dai_init+0x18c/0x2e0 [snd_soc_sdm845] snd_soc_link_init+0x28/0x6c snd_soc_bind_card+0x5f4/0xb0c snd_soc_register_card+0x148/0x1a4 devm_snd_soc_register_card+0x50/0xb0 sdm845_snd_platform_probe+0x124/0x148 [snd_soc_sdm845] platform_probe+0x6c/0xd0 really_probe+0xc0/0x2a4 __driver_probe_device+0x7c/0x130 driver_probe_device+0x40/0x118 __device_attach_driver+0xc4/0x108 bus_for_each_drv+0x8c/0xf0 __device_attach+0xa4/0x198 device_initial_probe+0x18/0x28 bus_probe_device+0xb8/0xbc deferred_probe_work_func+0xac/0xfc process_one_work+0x244/0x658 worker_thread+0x1b4/0x360 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Kernel panic - not syncing: BRK handler: Fatal exception Dan has also reported following issues with the original patch https://lore.kernel.org/all/33fe8fe7-719a-405a-9ed2-d9f816ce1d57@sabinyo.mountain/ Bug #1: se supone que el elemento cero de ctrl->pconfig[] no se utiliza. Empezamos a contar desde 1. Sin embargo, este código establece ctrl->pconfig[0].ch_mask = 128. Error n.° 2: Hay elementos SLIM_MAX_TX_PORTS (16) en la matriz tx_ch[], pero solo QCOM_SDW_MAX_PORTS + 1 (15) en la matriz ctrl->pconfig[], por lo que corrompe la memoria, como señaló Yongqin Liu. Error 3: Como señaló Jie Gan, borra toda la información de la transmisión junto con la de la recepción.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38489)
  Severidad: MEDIA
  Fecha de publicación: 28/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") eliminó accidentalmente la parte crítica del commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), lo que provocaba la reaparición de pánicos de kernel intermitentes en el programa on_switch() de perf, por ejemplo. Restablezca la corrección y añada un comentario.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38490)
  Severidad: ALTA
  Fecha de publicación: 28/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: libwx: eliminar la página duplicada page_pool_put_full_page(). page_pool_put_full_page() solo debe invocarse al liberar búferes Rx o al crear un skb si el tamaño es demasiado pequeño. En otros casos, es necesario reutilizar las páginas. Por lo tanto, se debe eliminar la página redundante. En el código original, las páginas doblemente libres provocan pánico en el núcleo:[ 876.949834] __irq_exit_rcu+0xc7/0x130 [ 876.949836] common_interrupt+0xb8/0xd0 [ 876.949838] [ 876.949838] [ 876.949840] asm_common_interrupt+0x22/0x40 [ 876.949841] RIP: 0010:cpuidle_enter_state+0xc2/0x420 [ 876.949843] Code: 00 00 e8 d1 1d 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 cd fc 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 876.949844] RSP: 0018:ffffaa7340267e78 EFLAGS: 00000246 [ 876.949845] RAX: ffff9e3f135be000 RBX: 0000000000000002 RCX: 0000000000000000 [ 876.949846] RDX: 000000cc2dc4cb7c RSI: ffffffff89ee49ae RDI: ffffffff89ef9f9e [ 876.949847] RBP: ffff9e378f940800 R08: 0000000000000002 R09: 00000000000000ed [ 876.949848] R10: 000000000000afc8 R11: ffff9e3e9e5a9b6c R12: ffffffff8a6d8580 [ 876.949849] R13: 000000cc2dc4cb7c R14: 0000000000000002 R15: 0000000000000000 [ 876.949852] ? cpuidle_enter_state+0xb3/0x420 [ 876.949855] cpuidle_enter+0x29/0x40 [ 876.949857] cpuidle_idle_call+0xfd/0x170 [ 876.949859] do_idle+0x7a/0xc0 [ 876.949861] cpu_startup_entry+0x25/0x30 [ 876.949862] start_secondary+0x117/0x140 [ 876.949864] common_startup_64+0x13e/0x148 [ 876.949867] [ 876.949868] ---[ end trace 0000000000000000 ]--- [ 876.949869] ------------[ cut here ]------------ [ 876.949870] list_del corruption, ffffead40445a348->next is NULL [ 876.949873] WARNING: CPU: 14 PID: 0 at lib/list_debug.c:52 __list_del_entry_valid_or_report+0x67/0x120 [ 876.949875] Modules linked in: snd_hrtimer(E) bnep(E) binfmt_misc(E) amdgpu(E) squashfs(E) vfat(E) loop(E) fat(E) amd_atl(E) snd_hda_codec_realtek(E) intel_rapl_msr(E) snd_hda_codec_generic(E) intel_rapl_common(E) snd_hda_scodec_component(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) edac_mce_amd(E) snd_intel_dspcfg(E) snd_hda_codec(E) snd_hda_core(E) amdxcp(E) kvm_amd(E) snd_hwdep(E) gpu_sched(E) drm_panel_backlight_quirks(E) cec(E) snd_pcm(E) drm_buddy(E) snd_seq_dummy(E) drm_ttm_helper(E) btusb(E) kvm(E) snd_seq_oss(E) btrtl(E) ttm(E) btintel(E) snd_seq_midi(E) btbcm(E) drm_exec(E) snd_seq_midi_event(E) i2c_algo_bit(E) snd_rawmidi(E) bluetooth(E) drm_suballoc_helper(E) irqbypass(E) snd_seq(E) ghash_clmulni_intel(E) sha512_ssse3(E) drm_display_helper(E) aesni_intel(E) snd_seq_device(E) rfkill(E) snd_timer(E) gf128mul(E) drm_client_lib(E) drm_kms_helper(E) snd(E) i2c_piix4(E) joydev(E) soundcore(E) wmi_bmof(E) ccp(E) k10temp(E) i2c_smbus(E) gpio_amdpt(E) i2c_designware_platform(E) gpio_generic(E) sg(E) [ 876.949914] i2c_designware_core(E) sch_fq_codel(E) parport_pc(E) drm(E) ppdev(E) lp(E) parport(E) fuse(E) nfnetlink(E) ip_tables(E) ext4 crc16 mbcache jbd2 sd_mod sfp mdio_i2c i2c_core txgbe ahci ngbe pcs_xpcs libahci libwx r8169 phylink libata realtek ptp pps_core video wmi [ 876.949933] CPU: 14 UID: 0 PID: 0 Comm: swapper/14 Kdump: loaded Tainted: G W E 6.16.0-rc2+ #20 PREEMPT(voluntary) [ 876.949935] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE [ 876.949936] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 876.949936] RIP: 0010:__list_del_entry_valid_or_report+0x67/0x120 [ 876.949938] Code: 00 00 00 48 39 7d 08 0f 85 a6 00 00 00 5b b8 01 00 00 00 5d 41 5c e9 73 0d 93 ff 48 89 fe 48 c7 c7 a0 31 e8 89 e8 59 7c b3 ff <0f> 0b 31 c0 5b 5d 41 5c e9 57 0d 93 ff 48 89 fe 48 c7 c7 c8 31 e8 [ 876.949940] RSP: 0018:ffffaa73405d0c60 EFLAGS: 00010282 [ 876.949941] RAX: 0000000000000000 RBX: ffffead40445a348 RCX: 0000000000000000 [ 876.949942] RDX: 0000000000000105 RSI: 00000 ---truncated---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38492)
  Severidad: MEDIA
  Fecha de publicación: 28/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Corregir la ejecución entre la finalización de la escritura en caché y el establecimiento de ALL_QUEUED Cuando netfslib emite subsolicitudes, estas empiezan a procesarse inmediatamente y pueden completarse antes de que lleguemos al final de la función de emisión. Al final de la función de emisión, establecemos NETFS_RREQ_ALL_QUEUED para indicar al recolector que no vamos a emitir más subsolicitudes y que puede realizar las notificaciones finales y la limpieza. Ahora bien, esto no es un problema si la solicitud es sincrónica (NETFS_RREQ_OFFLOAD_COLLECTION no está establecido), ya que la recopilación de resultados se realizará en el subproceso y se nos garantiza una oportunidad para ejecutar el recolector. Sin embargo, si la solicitud es asincrónica, la recopilación se activa principalmente al finalizar las subsolicitudes que la ponen en cola en una cola de trabajo. Ahora bien, aquí puede producirse una ejecución si el subproceso de la aplicación establece ALL_QUEUED después de que finalice la última subsolicitud. Esto se puede lograr más fácilmente con el código copy2cache (usado por Ceph), donde, en la rutina de recopilación de una solicitud de lectura, se genera una solicitud de escritura asíncrona para copiar datos a la caché. Los folios se agregan a la solicitud de escritura a medida que se desbloquean, pero puede haber un retraso antes de que se configure ALL_QUEUED, ya que las subsolicitudes de escritura pueden completarse antes de que lleguemos a ese punto. Si todas las subsolicitudes de escritura han finalizado para el punto ALL_QUEUED, no ocurren más eventos y la recopilación nunca se realiza, dejando la solicitud colgada. Para solucionar esto, ponga en cola el recopilador después de configurar ALL_QUEUED. Esto es un poco forzado y podría ser suficiente si no existen subsolicitudes. También agregue un punto de seguimiento para realizar una referencia cruzada de ambas solicitudes en una operación de copia a solicitud y agregue un seguimiento al punto de seguimiento netfs_rreq para indicar la configuración de ALL_QUEUED.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38493)
  Severidad: MEDIA
  Fecha de publicación: 28/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/osnoise: corrige fallo en timerlat_dump_stack() Hemos observado pánicos en el kernel al usar timerlat con guardado de pila, con la siguiente salida de dmesg: memcpy: desbordamiento de búfer detectado: escritura de 88 bytes de tamaño de búfer 0 WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e __timerlat_dump_stack() construye la entrada de la pila ftrace de la siguiente manera: struct stack_entry *entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nr_entries; Desde el commit e7186af7fb26 ("rastreo: Agregar la lógica de FORTIFY_SOURCE a la estructura de eventos kernel_stack"), struct stack_entry marca su campo de llamada con __counted_by(size). Al ejecutar memcpy, entry->size contiene información no válida del búfer de anillo, que en algunas circunstancias es cero, lo que desencadena un pánico del núcleo por desbordamiento del búfer. Rellene el campo de tamaño antes de ejecutar memcpy para que la comprobación de fuera de los límites conozca el tamaño correcto. Esto es análogo a __ftrace_trace_stack().
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38496)
  Severidad: MEDIA
  Fecha de publicación: 28/07/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-bufio: corrección de sched en contexto atómico Si "try_verify_in_tasklet" está configurado para dm-verity, DM_BUFIO_CLIENT_NO_SLEEP está habilitado para dm-bufio. Sin embargo, cuando bufio intenta expulsar búfer, existe la posibilidad de activar la programación en spin_lock_bh, se muestra la siguiente advertencia: BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2 preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by kworker/2:2/123: #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970 #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: dm_bufio_cache do_global_cleanup Call Trace: dump_stack_lvl+0x53/0x70 __might_resched+0x360/0x4e0 do_global_cleanup+0x2f5/0x710 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0xf3/0x1b0 ret_from_fork_asm+0x1a/0x30 That can be reproduced by: veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 1 sha256 1 try_verify_in_tasklet" mount /dev/dm-0 /mnt -o ro echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes [read files in /mnt]
  
• Vulnerabilidad en kernel de Linux (CVE-2022-50233)
  Severidad: MEDIA
  Fecha de publicación: 09/08/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: eir: Corrección del uso de strlen con hdev->{dev_name,short_name} No se garantiza que dev_name y short_name terminen en NULL, por lo que en su lugar se utiliza strnlen y luego se intenta determinar si la cadena resultante debe truncarse o no.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-58238)
  Severidad: MEDIA
  Fecha de publicación: 09/08/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btnxpuart: resolver error de tiempo de espera de TX en la prueba de esfuerzo de ahorro de energía Esto corrige el problema de tiempo de espera de TX observado al ejecutar una prueba de esfuerzo en btnxpuart durante un par de horas, de modo que el intervalo entre dos comandos HCI coincida con el valor de tiempo de espera de ahorro de energía de 2 segundos. Procedimiento de prueba usando script bash: hciconfig hci0 up //Habilitar función de ahorro de energía hcitool -i hci0 cmd 3f 23 02 00 00 while (true) do hciconfig hci0 leadv sleep 2 hciconfig hci0 noleadv sleep 2 done Registro de errores, después de agregar algunas impresiones de depuración más: Bluetooth: btnxpuart_queue_skb(): 01 0A 20 01 00 Bluetooth: hci0: Establecer UART break: activado, estado=0 Bluetooth: hci0: btnxpuart_tx_wakeup() tx_work programado Bluetooth: hci0: btnxpuart_tx_work() dequeue: 01 0A 20 01 00 No se puede establecer el modo de anuncio en hci0: Se agotó el tiempo de conexión (110) Bluetooth: hci0: comando 0x200a Tiempo de espera de TX: Cuando el mecanismo de ahorro de energía activa la interrupción de UART y btnxpuart_tx_work() se programa simultáneamente, psdata->ps_state se lee como PS_STATE_AWAKE, lo que impide que se programe psdata->work, que es responsable de desactivar la interrupción de UART. Este problema se soluciona añadiendo un mutex ps_lock alrededor de la activación/desactivación de la interrupción de UART, así como alrededor de la lectura/escritura de ps_state. btnxpuart_tx_wakeup() ahora leerá el valor actualizado de ps_state. Si ps_state es PS_STATE_SLEEP, primero programará psdata->work y luego se reprogramará a sí mismo una vez que la interrupción de UART se haya desactivado y ps_state sea PS_STATE_AWAKE. Probé el script anterior durante 50,000 iteraciones y el error de tiempo de espera de TX ya no se observó.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38504)
  Severidad: MEDIA
  Fecha de publicación: 16/08/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/zcrx: corrección de advertencias de destrucción de pp. Con varios grupos de páginas y en otros casos, podemos asignar niovs al destruir el grupo de páginas. Se ha eliminado una advertencia incorrecta que verificaba que todos los niovs se devolvieran a zcrx en io_pp_zc_destroy(). Se informó anteriormente, pero aparentemente se perdió.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38505)
  Severidad: MEDIA
  Fecha de publicación: 16/08/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: descarta marcos de disociación erróneos en la interfaz STA. Cuando se opera en modo STA/AP concurrente con MLME de host habilitado, el firmware envía incorrectamente marcos de disociación a la interfaz STA cuando los clientes se desconectan de la interfaz AP. Esto genera advertencias del kernel ya que la interfaz STA procesa eventos de desconexión que no se aplican a ella: [ 1303.240540] ADVERTENCIA: CPU: 0 PID: 513 en net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.250861] Módulos vinculados: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us [ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 No contaminado 6.16.0-rc1+ #3 PREEMPT [ 1303.335937] Nombre del hardware: Toradex Verdin AM62 WB en placa de desarrollo Verdin (DT) [ 1303.343588] Cola de trabajo: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211] [ 1303.370221] sp : ffff800083053be0 [ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 00000000000000000 [ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae [ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008 [ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006 [ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048 [ 1303.409910] x14: ffff000003625300 x13: 000000000000001 x12: 0000000000000000 [ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300 [ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002 [ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186 [ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de [ 1303.446221] Rastreo de llamadas: [ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P) [ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211] [ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex] [ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex] [ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex] [ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex] [ 1303.483734] process_one_work+0x14c/0x28c [ 1303.487845]worker_thread+0x2cc/0x3d4 [ 1303.491680] kthread+0x12c/0x208 [ 1303.495014] ret_from_fork+0x10/0x20 Agregue validación en la ruta de recepción de STA para verificar que los marcos de desasociación/desautorización se originen en el AP conectado. Las tramas que no superan esta comprobación se descartan prematuramente, lo que impide que lleguen a la capa MLME y activen WARN_ON(). Esta lógica de filtrado es similar a la utilizada en la función ieee80211_rx_mgmt_disassoc() de mac80211, que descarta las tramas de desasociación que no coinciden con el BSSID actual (!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), garantizando así que solo se procesen las tramas relevantes. Probado en: - 8997 con firmware 16.68.1.p197
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38506)
  Severidad: MEDIA
  Fecha de publicación: 16/08/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: Permitir que la CPU reprograme mientras se configuran atributos de memoria por página Cuando se ejecuta un invitado SEV-SNP con una cantidad de memoria suficientemente grande (1 TB+), el host puede experimentar bloqueos suaves de la CPU cuando ejecuta una operación en kvm_vm_set_mem_attributes() para configurar los atributos de memoria en todo el rango de memoria del invitado. watchdog: BUG: bloqueo suave: ¡CPU n.º 8 bloqueada durante 26 s! [qemu-kvm:6372] CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: cargado No contaminado 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntario) Nombre del hardware: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 13/11/2024 RIP: 0010:xas_create+0x78/0x1f0 Código: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87 RSP: 0018:ffffad890a34b940 EFLAGS: 00000286 RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 00000000000000000 RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868 R13: ffffad890a356860 R14: 000000000000000 R15: ffffad890a356868 FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0 PKRU: 55555554 Rastreo de llamadas: xas_store+0x58/0x630 __xa_store+0xa5/0x130 xa_store+0x2c/0x50 kvm_vm_set_mem_attributes+0x343/0x710 [kvm] kvm_vm_ioctl+0x796/0xab0 [kvm] __x64_sys_ioctl+0xa3/0xd0 do_syscall_64+0x8c/0x7a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f5578d031bb Código: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 00000000000000b RBP: 000001000000000 R08: 0000010000000000 R09: 0000017680000000 R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120 R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0 Mientras recorre el rango de memoria configurando los atributos, llame a cond_resched() para darle al programador la oportunidad de ejecutar una tarea de mayor prioridad en la cola de ejecución si es necesario y evitar permanecer en modo kernel el tiempo suficiente para activar el bloqueo.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38507)
  Severidad: MEDIA
  Fecha de publicación: 16/08/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: nintendo: evitar bloqueos de suspensión/reinicio de bluetooth Asegúrese de que no bloqueemos ni hagamos que el kernel entre en pánico cuando usemos controladores conectados por bluetooth. Esto se informó como un problema en dispositivos Android que usan el kernel 6.6 debido al gancho de reanudación que se había agregado para los joycons usb. Primero, establezca un nuevo valor de estado en JOYCON_CTLR_STATE_SUSPENDED en un nintendo_hid_suspend recién agregado. Esto asegura que no bloquearemos el kernel esperando informes de entrada durante la suspensión de classdev led. Los bloqueos podrían ocurrir si la conectividad no es confiable o se pierde con el controlador antes de la suspensión. Segundo, dado que perdemos la conectividad durante la suspensión, no intentes joycon_init() para controladores bluetooth en la ruta nintendo_hid_resume. Probado a través de múltiples flujos de suspensión/reinicio al usar el controlador en modo USB y bluetooth.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38508)
  Severidad: MEDIA
  Fecha de publicación: 16/08/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/sev: Usar TSC_FACTOR para el cálculo de frecuencia de Secure TSC. Al usar Secure TSC, el MSR GUEST_TSC_FREQ informa una frecuencia basada en la frecuencia P0 nominal, que se desvía ligeramente (normalmente ~0,2 %) de la frecuencia media real de TSC debido a los parámetros de reloj. Con el tiempo de actividad prolongado de la máquina virtual, esta discrepancia se acumula, causando un sesgo de reloj entre el hipervisor y una máquina virtual SEV-SNP, lo que lleva a interrupciones tempranas del temporizador según lo percibe el invitado. El kernel invitado se basa en la frecuencia nominal informada para el control de tiempo basado en TSC, mientras que la frecuencia real establecida durante SNP_LAUNCH_START puede diferir. Esta falta de coincidencia resulta en cálculos de tiempo inexactos, lo que hace que el invitado perciba que los temporizadores hr se activan antes de lo esperado. Utilice el factor TSC_FACTOR de la página de secretos del firmware SEV (consulte "Formato de la página de secretos" en la especificación ABI del firmware SNP) para calcular la frecuencia media de TSC, lo que garantiza una sincronización precisa y mitiga el desfase de reloj en las máquinas virtuales SEV-SNP. Utilice early_ioremap_encrypted() para mapear la página de secretos, ya que ioremap_encrypted() utiliza kmalloc(), que no está disponible durante la inicialización temprana de TSC y provoca un pánico. [bp: Eliminar la variable ficticia: https://lore.kernel.org/r/20250630192726.GBaGLlHl84xIopx4Pt@fat_crate.local]
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38509)
  Severidad: MEDIA
  Fecha de publicación: 16/08/2025
  Fecha de última actualización: 19/11/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: rechazar el modo de operación VHT para anchos de canal no compatibles. Las notificaciones del modo de operación VHT no están definidas para anchos de canal inferiores a 20 MHz. En particular, 5 MHz y 10 MHz no son válidos según la especificación VHT y deben rechazarse. Sin esta comprobación, las notificaciones malformadas que utilicen estos anchos pueden alcanzar ieee80211_chan_width_to_rx_bw(), lo que genera un WARN_ON debido a una entrada no válida. Este problema fue reportado por syzbot. Rechace estos anchos no compatibles al principio de sta_link_apply_parameters() cuando se utilice opmode_notif. El conjunto aceptado incluye 20, 40, 80, 160 y 80+80 MHz, que son válidos para VHT. Si bien 320 MHz no está definido para VHT, se permite evitar rechazar clientes HE o EHT que aún puedan enviar una notificación de modo de operación VHT.