Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: Comprobar la disponibilidad de la cola de trabajo asignada por el controlador wq de idxd antes de usarla. Ejecutar cargas de trabajo IDXD en un contenedor con el directorio /dev montado puede provocar un seguimiento de llamadas o incluso un pánico del kernel cuando finaliza el proceso principal del contenedor. Este problema se produce porque, en ciertas configuraciones, Docker no propaga correctamente la réplica de montaje al punto de montaje original. En este caso, al desconectarse el controlador de usuario, la cola de trabajo se destruye, pero sigue llamando a destroy_workqueue() para intentar completar todo el trabajo pendiente. Es necesario comprobar wq->wq y omitir el vaciado si ya no existe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el error al reconstruir el árbol de espacio libre utilizando múltiples transacciones Si estamos reconstruyendo un árbol de espacio libre, mientras modificamos el árbol de espacio libre, es posible que necesitemos asignar un nuevo grupo de bloques de metadatos. Si terminamos utilizando múltiples transacciones para la reconstrucción, cuando llamamos a btrfs_end_transaction() ingresamos btrfs_create_pending_block_groups() que llama a add_block_group_free_space() para agregar elementos al árbol de espacio libre para el grupo de bloques. Luego, más tarde durante la reconstrucción del árbol de espacio libre, en btrfs_rebuild_free_space_tree(), podemos encontrar dichos nuevos grupos de bloques y llamar a populate_free_space_tree() para ellos, lo que falla con -EEXIST porque ya hay elementos en el árbol de espacio libre. Luego abortamos la transacción con -EEXIST en btrfs_rebuild_free_space_tree(). Tenga en cuenta que decimos "puede encontrar" los nuevos grupos de bloques porque se puede insertar un nuevo grupo de bloques en el árbol de grupos de bloques, que está siendo iterado por el proceso de reconstrucción, antes o después del nodo actual en el que se encuentra actualmente el proceso de reconstrucción. Syzbot informó recientemente de un caso similar que produce un seguimiento como el siguiente: ------------[ cut here ]------------ BTRFS: Transaction aborted (error -17) WARNING: CPU: 1 PID: 7626 at fs/btrfs/free-space-tree.c:1341 btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 Modules linked in: CPU: 1 UID: 0 PID: 7626 Comm: syz.2.25 Not tainted 6.15.0-rc7-syzkaller-00085-gd7fa1af5b33e-dirty #0 PREEMPT 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 : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 lr : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 sp : ffff80009c4f7740 x29: ffff80009c4f77b0 x28: ffff0000d4c3f400 x27: 0000000000000000 x26: dfff800000000000 x25: ffff70001389eee8 x24: 0000000000000003 x23: 1fffe000182b6e7b x22: 0000000000000000 x21: ffff0000c15b73d8 x20: 00000000ffffffef x19: ffff0000c15b7378 x18: 1fffe0003386f276 x17: ffff80008f31e000 x16: ffff80008adbe98c x15: 0000000000000001 x14: 1fffe0001b281550 x13: 0000000000000000 x12: 0000000000000000 x11: ffff60001b281551 x10: 0000000000000003 x9 : 1c8922000a902c00 x8 : 1c8922000a902c00 x7 : ffff800080485878 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff80008047843c x2 : 0000000000000001 x1 : ffff80008b3ebc40 x0 : 0000000000000001 Call trace: btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 (P) btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __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/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 irq event stamp: 330 hardirqs last enabled at (329): [] raw_spin_rq_unlock_irq kernel/sched/sched.h:1525 [inline] hardirqs last enabled at (329): [] finish_lock_switch+0xb0/0x1c0 kernel/sched/core.c:5130 hardirqs last disabled at (330): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:511 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige una ejecución entre los cambios de nombre y el registro de directorios Tenemos una ejecución entre un cambio de nombre y el registro del inodo del directorio que, si ocurre y nos bloqueamos o falla la energía antes de que se complete el cambio de nombre, la próxima vez que se monte el sistema de archivos, el código de reproducción del registro terminará eliminando el archivo que se estaba cambiando de nombre. Esto se explica mejor siguiendo un análisis paso a paso de un intercalado de pasos que conducen a esta situación. Considere las condiciones iniciales: 1) Estamos en la transacción N; 2) Tenemos los directorios A y B creados en una transacción anterior (< N); 3) Tenemos el inodo X correspondiente a un archivo que tiene 2 enlaces duros, uno en el directorio A y el otro en el directorio B, por lo que los nombraremos como "A/foo_link1" y "B/foo_link2". Ambos enlaces duros persistieron en una transacción anterior (< N); 4) Tenemos el inodo Y, correspondiente a un archivo con un único enlace físico ubicado en el directorio A, al que llamaremos "A/bar". Este archivo también se conservó en una transacción anterior (< N). Los pasos que conducen a la pérdida del archivo son los siguientes, y para todos ellos, estamos en la transacción N: 1) Se elimina el enlace "A/foo_link1", por lo que el campo X last_unlink_trans del inodo se actualiza a N mediante btrfs_unlink() -> btrfs_record_unlink_dir(); 2) La tarea A inicia un cambio de nombre para el inodo Y, con el objetivo de cambiar de "A/bar" a "A/baz", por lo que introducimos btrfs_rename(); 3) La tarea A inserta la nueva clave BTRFS_INODE_REF_KEY para el inodo Y mediante la llamada a btrfs_insert_inode_ref(); 4) Debido a que el cambio de nombre ocurre en el mismo directorio, no establecemos el campo last_unlink_trans del inodo del directorio A en el id de transacción actual, es decir, no llamamos a btrfs_record_unlink_dir(); 5) Luego, la tarea A elimina las entradas del directorio A (elementos BTRFS_DIR_ITEM_KEY y BTRFS_DIR_INDEX_KEY) cuando llama a __btrfs_unlink_inode() (en realidad, el elemento de índice del directorio se agrega como un elemento retrasado, pero el efecto es el mismo); 6) Ahora, antes de que la tarea A agregue la nueva entrada "A/baz" al directorio A llamando a btrfs_add_link(), otra tarea, la tarea B, está registrando el inodo X; 7) La tarea B inicia una sincronización fsync del inodo X y, tras registrarlo, en btrfs_log_inode_parent() llama a btrfs_log_all_parents(), ya que el inodo X tiene un valor de last_unlink_trans de N, establecido en el paso 1. 8) En btrfs_log_all_parents() buscamos todos los directorios padre del inodo X utilizando un root commit, por lo que encontramos los directorios A y B y los registramos. Sin embargo, al registrar directamente A, ya no tenemos un elemento de índice de directorio para el inodo Y, ni para el nombre antiguo "A/bar" ni para el nuevo nombre "A/baz", ya que el cambio de nombre ha eliminado el nombre antiguo, pero aún no ha insertado el nuevo. La tarea A aún no ha llamado a btrfs_add_link() para hacerlo. Tenga en cuenta que registrar el directorio A no recurre a un commit de transacción porque su valor de last_unlink_trans es menor que el ID de la transacción actual (véase el paso 4). 9) La tarea B finaliza el registro de los directorios A y B y regresa a btrfs_sync_file(), donde invoca btrfs_sync_log() para persistir el árbol de registro. 10) La tarea B persistió correctamente el árbol de registro, btrfs_sync_log() se completó correctamente y se produjo un corte de energía. Tenemos un árbol de registro sin ninguna entrada de directorio para el inodo Y, por lo que el código de reproducción del registro elimina la entrada del inodo Y, llamada "A/bar", del árbol de subvolumen, ya que no existe en el árbol de registro y este es autoritario para su índice (registramos un elemento BTRFS_DIR_LOG_INDEX_KEY que cubre el rango de índices de la entrada dentry correspondiente a "A/bar"). ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: KVM: verificar la validez de "num_cpu" desde el espacio del usuario. El número máximo de CPU admitido es EIOINTC_ROUTE_MAX_VCPUS sobre irqchip EIOINTC, aquí agregue validación sobre el número de CPU para evitar el desbordamiento del puntero de la matriz.

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.

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/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/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: 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: 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: 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: 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)