Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: maple_tree: corrección del indicador MA_STATE_PREALLOC en mas_preallocate(). Borra temporalmente el indicador de preasignación al solicitar asignaciones explícitamente. Las asignaciones preexistentes ya se contabilizan en la solicitud mediante mas_node_count_gfp(), pero las asignaciones no se realizarán si el indicador MA_STATE_PREALLOC está activado. Este indicador evita la reasignación en modo de asignación masiva y detecta problemas con los cálculos de preasignación. El indicador MA_STATE_PREALLOC debe estar siempre activado en asignaciones cero para que la detección de asignaciones por desbordamiento imprima un WARN_ON() durante el consumo. El efecto visible para el usuario de esta falla es un WARN_ON() seguido de una desreferencia de puntero nulo cuando se ignoran solicitudes posteriores de un mayor número de nodos, como el reintento de fusión de vma en mmap_region() causado por controladores que alteran los indicadores de vma (al menos en la versión 6.6).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/tegra: Se corrige una posible desreferencia de puntero nulo. En tegra_crtc_reset(), se asigna nueva memoria con kzalloc(), pero no se realiza ninguna comprobación. Antes de llamar a __drm_atomic_helper_crtc_reset, se debe comprobar el estado para evitar una posible desreferencia de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se ha añadido una comprobación de puntero nulo para get_first_active_display(). La función mod_hdcp_hdcp1_enable_encryption() llama a la función get_first_active_display(), pero no comprueba su valor de retorno. El valor de retorno es un puntero nulo si la lista de visualización está vacía. Esto provocará una desreferencia de puntero nulo en mod_hdcp_hdcp2_enable_encryption(). Se ha añadido una comprobación de puntero nulo para get_first_active_display() y se ha devuelto MOD_HDCP_STATUS_DISPLAY_NOT_FOUND si la función devuelve un valor nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/guc: Salida explícita del modo seguro CT al desenrollar. Durante la prueba del controlador, podríamos usar brevemente el modo seguro CT, que se basa en un trabajo retrasado, pero normalmente podemos detenerlo una vez que IRQ esté completamente operativo. Sin embargo, si cancelamos la prueba antes de tiempo, durante la desenrollación podríamos intentar destruir la cola de trabajos mientras aún haya un trabajo retrasado pendiente que intenta reiniciarse, lo que activa una advertencia. Esto se observó recientemente durante una inicialización de VF fallida: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] ------------[ cut here ]------------ [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710 [ ] RIP: 0010:__queue_work+0x287/0x710 [ ] Call Trace: [ ] delayed_work_timer_fn+0x19/0x30 [ ] call_timer_fn+0xa1/0x2a0 Salga del modo seguro de CT al desenrollar para evitar esa advertencia. (seleccionado del commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Proceso diferido de eliminaciones de nodos GGTT al desenrollar el dispositivo Mientras drenamos indirectamente nuestra cola de trabajo dedicada ggtt->wq que usamos para completar la eliminación asincrónica de algunos nodos GGTT, esto sucede como parte del desenrollado de managed-drm (ggtt_fini_early), que podría ser posterior al desenrollado de managed-device, donde ya podríamos desasignar nuestra asignación MMIO/GMS (mmio_fini). Esto se observó recientemente durante una inicialización de VF fallida: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes) and this was leading to: [ ] BUG: unable to handle page fault for address: ffffc900058162a0 [ ] #PF: supervisor write access in kernel mode [ ] #PF: error_code(0x0002) - not-present page [ ] Oops: Oops: 0002 [#1] SMP NOPTI [ ] Tainted: [W]=WARN [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe] [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe] [ ] Call Trace: [ ] [ ] xe_ggtt_clear+0xb0/0x270 [xe] [ ] ggtt_node_remove+0xbb/0x120 [xe] [ ] ggtt_node_remove_work_func+0x30/0x50 [xe] [ ] process_one_work+0x22b/0x6f0 [ ] worker_thread+0x1e8/0x3d Se agregó una acción de dispositivo administrado que drenará explícitamente la cola de trabajo con todas las eliminaciones de nodos pendientes antes de liberar la asignación de MMIO/GSM. (Seleccionado del commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se han añadido más comprobaciones para las garantías de DSC/HUBP ONO [WHY] En instancias DSC con valores distintos de cero, es posible que no se cumpla el dominio HUBP necesario para controlarlas en ASIC ONO secuenciales, lo que podría provocar que la lógica del mosaico entre en un estado indefinido y provoque un bloqueo del sistema. [HOW] Se han añadido más comprobaciones para garantizar que el dominio HUBP correspondiente a la instancia DSC reciba la alimentación adecuada. (Seleccionado del commit da63df07112e5a9857a8d2aaa04255c4206754ec)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/mm: Se corrige la gestión de in_atomic() en do_secure_storage_access(). Los accesos a espacios de usuario del kernel a páginas no exportadas en contexto atómico intentan resolver incorrectamente el fallo de página. Con las opciones de depuración habilitadas, se pueden observar seguimientos de llamadas como este: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. Preemption disabled at: [<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0 CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39 Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT Tainted: [W]=WARN Hardware name: IBM 3931 A01 703 (LPAR) Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0 ([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90 INFO: lockdep is turned off. No se permite usar mmap_lock en contexto atómico. Por lo tanto, se gestiona un fallo de acceso al almacenamiento seguro como si la página accedida no estuviera mapeada: la función uaccess devolverá -EFAULT, y el usuario que realiza la llamada debe gestionarlo. Normalmente, esto significa que se reintenta el acceso en contexto de proceso, lo que permite resolver el fallo de página (o, en este caso, exportar la página).

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

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

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

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

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