Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrección de slab-use-after-free en amdgpu_userq_mgr_fini+0x70c. El problema se reprodujo en NV10 mediante la prueba pci_unplug de IGT. Se espera que `amdgpu_driver_postclose_kms()` se llame antes que `amdgpu_drm_release()`. Sin embargo, el error radica en que `amdgpu_fpriv` se liberó en `amdgpu_driver_postclose_kms()` y luego se accedió a él en `amdgpu_drm_release()` mediante una llamada a `amdgpu_userq_mgr_fini()`. Como resultado, KASAN detectó una condición de use-after-free, como se muestra en el registro a continuación. La solución propuesta es mover las llamadas a `amdgpu_eviction_fence_destroy()` y `amdgpu_userq_mgr_fini()` a `amdgpu_driver_postclose_kms()`, de modo que se invoquen antes de que se libere `amdgpu_fpriv`. Esto también garantiza la simetría con la ruta de inicialización en `amdgpu_driver_open_kms()`, donde se inicializan los siguientes componentes: - `amdgpu_userq_mgr_init()` - `amdgpu_eviction_fence_init()` - `amdgpu_ctx_mgr_init()` En consecuencia, en `amdgpu_driver_postclose_kms()` debemos limpiar usando: - `amdgpu_userq_mgr_fini()` - `amdgpu_eviction_fence_destroy()` - `amdgpu_ctx_mgr_fini()` Este cambio elimina el use-after-free y mejora la consistencia en la gestión de recursos entre las rutas de apertura y cierre. [ +0.094367] ====================================================================== [ +0.000026] ERROR: KASAN: slab-use-after-free in amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000866] Write of size 8 at addr ffff88811c068c60 by task amd_pci_unplug/1737 [ +0.000026] CPU: 3 UID: 0 PID: 1737 Comm: amd_pci_unplug Not tainted 6.14.0+ #2 [ +0.000008] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000004] Call Trace: [ +0.000004] [ +0.000003] dump_stack_lvl+0x76/0xa0 [ +0.000010] print_report+0xce/0x600 [ +0.000009] ? amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000790] ? srso_return_thunk+0x5/0x5f [ +0.000007] ? kasan_complete_mode_report_info+0x76/0x200 [ +0.000008] ? amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000684] kasan_report+0xbe/0x110 [ +0.000007] ? amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000601] __asan_report_store8_noabort+0x17/0x30 [ +0.000007] amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000801] ? __pfx_amdgpu_userq_mgr_fini+0x10/0x10 [amdgpu] [ +0.000819] ? srso_return_thunk+0x5/0x5f [ +0.000008] amdgpu_drm_release+0xa3/0xe0 [amdgpu] [ +0.000604] __fput+0x354/0xa90 [ +0.000010] __fput_sync+0x59/0x80 [ +0.000005] __x64_sys_close+0x7d/0xe0 [ +0.000006] x64_sys_call+0x2505/0x26f0 [ +0.000006] do_syscall_64+0x7c/0x170 [ +0.000004] ? kasan_record_aux_stack+0xae/0xd0 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? kmem_cache_free+0x398/0x580 [ +0.000006] ? __fput+0x543/0xa90 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __fput+0x543/0xa90 [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000007] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? fpregs_assert_state_consistent+0x21/0xb0 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? syscall_exit_to_user_mode+0x4e/0x240 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? do_syscall_64+0x88/0x170 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? do_syscall_64+0x88/0x170 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? irqentry_exit+0x43/0x50 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? exc_page_fault+0x7c/0x110 [ +0.000006] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000005] RIP: 0033:0x7ffff7b14f67 [ +0.000005] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 73 ba f7 ff [ +0.000004] RSP: 002b:00007fffffffe358 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000006] RAX: ffffffffff ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtl818x: Eliminar URBs antes de borrar la cola de estado de la transmisión. En rtl8187_stop(), la llamada a usb_kill_anchored_urbs() se desplaza antes de borrar b_tx_status.queue. Este cambio impide que las devoluciones de llamada utilicen skb ya liberados, ya que el ancla no se eliminó antes de liberar dicho skb. ERROR: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 Probado en el dispositivo RTL8187BvE. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iwlwifi: Agregar verificación faltante para alloc_ordered_workqueue Agregar verificación para el valor de retorno de alloc_ordered_workqueue ya que puede devolver un puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: borrar el indicador inicializado para listas srng desiniciadas En varios casos, vemos pánicos del kernel al reanudarse debido a un fallo de página del kernel ath11k, que sucede en las siguientes circunstancias: 1) Primera llamada a ath11k_hal_dump_srng_stats() Última interrupción recibida para cada grupo: ath11k_pci 0000:01:00.0: group_id 0 22511ms antes ath11k_pci 0000:01:00.0: group_id 1 14440788ms antes [..] ath11k_pci 0000:01:00.0: no se pudo recibir la respuesta de control finalización, sondeo.. ath11k_pci 0000:01:00.0: tiempo de espera de conexión del servicio ath11k_pci 0000:01:00.0: no se pudo conectar a HTT: -110 ath11k_pci 0000:01:00.0: no se pudo iniciar el núcleo: -110 ath11k_pci 0000:01:00.0: el firmware falló: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: ya se está restableciendo el recuento 2 ath11k_pci 0000:01:00.0: no se pudo esperar la solicitud de modo wlan (modo 4): -110 ath11k_pci 0000:01:00.0: qmi no pudo enviar el modo wlan desactivado: -110 ath11k_pci 0000:01:00.0: no se pudo reconfigurar el controlador en la recuperación de falla [..] 2) En este punto, la reconfiguración falla (tenemos 2 Se reinicia) y ath11k_core_reconfigure_on_crash() llama a ath11k_hal_srng_deinit(), que destruye las listas srng. Sin embargo, no reinicia el indicador de inicialización por lista. 3) La segunda llamada ath11k_hal_dump_srng_stats() ve la bandera obsoleta ->inicializada e intenta volcar las estadísticas de srng: Última interrupción recibida para cada grupo: ath11k_pci 0000:01:00.0: group_id 0 66785ms antes ath11k_pci 0000:01:00.0: group_id 1 14485062ms antes ath11k_pci 0000:01:00.0: group_id 2 14485062ms antes ath11k_pci 0000:01:00.0: group_id 3 14485062ms antes ath11k_pci 0000:01:00.0: group_id 4 14780845ms antes ath11k_pci 0000:01:00.0: group_id 5 14780845ms antes ath11k_pci 0000:01:00.0: group_id 6 14485062ms antes ath11k_pci 0000:01:00.0: group_id 7 66814ms antes ath11k_pci 0000:01:00.0: group_id 8 68997ms antes ath11k_pci 0000:01:00.0: group_id 9 67588ms antes ath11k_pci 0000:01:00.0: group_id 10 69511ms antes ERROR: no se puede manejar el error de página para la dirección: ffffa007404eb010 #PF: lectura del supervisor acceso en modo kernel #PF: error_code(0x0000) - página no presente PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Seguimiento de llamadas: ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170 Limpiar la bandera por lista ->inicializada en ath11k_hal_srng_deinit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Evitar el acceso arvif->ar no inicializado durante un fallo de baliza. Durante la gestión de fallos de baliza, el controlador ath12k itera sobre interfaces virtuales activas (VIF) e intenta acceder al objeto de radio (AR) mediante arvif->deflink->ar. Sin embargo, tras el commit aa80f12f3bed ("wifi: ath12k: aplazar la creación de VDEV para MLO"), arvif se vincula a una radio solo después de la creación de VDEV, normalmente cuando se asigna un canal o se solicita un escaneo. Para dispositivos con capacidad P2P, wpa_supplicant crea una interfaz P2P predeterminada junto con las interfaces de estación normales. Estas sirven como interfaces ficticias para estaciones con capacidad P2P, carecen de un netdev asociado e inician escaneos frecuentes para descubrir dispositivos P2P vecinos. Al iniciar un escaneo en estos vifs P2P, el controlador selecciona la radio de destino (ar) según su frecuencia, crea un vdev de escaneo y asocia el arvif a la radio. Una vez que el escaneo se completa o se aborta, el vdev de escaneo se elimina, desconectando el arvif de la radio y dejando el archivo arvif->ar sin inicializar. Al gestionar fallos de baliza para las interfaces de estación, también se encuentra la interfaz P2P en la iteración del vif y ath12k_mac_handle_beacon_miss_iter() intenta desreferenciar el archivo arvif->deflink->ar sin inicializar. Para solucionar esto, verifique que el vdev se haya creado para el arvif antes de acceder a su ar durante la gestión de fallos de baliza y devoluciones de llamada similares del iterador vif. ============================================================================ wlp6s0: se detectó pérdida de baliza del AP (7 balizas perdidas) - sondeando KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 5 UID: 0 PID: 0 Comm: swapper/5 Not tainted 6.16.0-rc1-wt-ath+ #2 PREEMPT(full) RIP: 0010:ath12k_mac_handle_beacon_miss_iter+0xb5/0x1a0 [ath12k] Call Trace: __iterate_interfaces+0x11a/0x410 [mac80211] ieee80211_iterate_active_interfaces_atomic+0x61/0x140 [mac80211] ath12k_mac_handle_beacon_miss+0xa1/0xf0 [ath12k] ath12k_roam_event+0x393/0x560 [ath12k] ath12k_wmi_op_rx+0x1486/0x28c0 [ath12k] ath12k_htc_process_trailer.isra.0+0x2fb/0x620 [ath12k] ath12k_htc_rx_completion_handler+0x448/0x830 [ath12k] ath12k_ce_recv_process_cb+0x549/0x9e0 [ath12k] ath12k_ce_per_engine_service+0xbe/0xf0 [ath12k] ath12k_pci_ce_workqueue+0x69/0x120 [ath12k] process_one_work+0xe3a/0x1430 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7925: corrección de uno en mt7925_mcu_hw_scan() Las matrices ssid->ssids[] y sreq->ssids[] tienen elementos MT7925_RNR_SCAN_MAX_BSSIDS, por lo que esto >= debe ser > para evitar un acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Pasar el puntero ab directamente a ath12k_dp_tx_get_encap_type(). En ath12k_dp_tx_get_encap_type(), el parámetro arvif solo se usa para recuperar el puntero ab. En la secuencia de eliminación de vdev, arvif->ar podría volverse nulo, lo que provocaría un pánico del kernel. Dado que el llamador ath12k_dp_tx() ya tiene un puntero ab válido, páselo directamente para evitar el pánico y la desreferenciación innecesaria. El PC apunta a "ath12k_dp_tx+0x228/0x988 [ath12k]". El LR apunta a "ath12k_dp_tx+0xc8/0x988 [ath12k]". El backtrace obtenido es el siguiente: ath12k_dp_tx+0x228/0x988 [ath12k] ath12k_mac_tx_check_max_limit+0x608/0x920 [ath12k] ieee80211_process_measurement_req+0x320/0x348 [mac80211] ieee80211_tx_dequeue+0x9ac/0x1518 [mac80211] ieee80211_tx_dequeue+0xb14/0x1518 [mac80211] ieee80211_tx_prepare_skb+0x224/0x254 [mac80211] ieee80211_xmit+0xec/0x100 [mac80211] __ieee80211_subif_start_xmit+0xc50/0xf40 [mac80211] ieee80211_subif_start_xmit+0x2e8/0x308 [mac80211] netdev_start_xmit+0x150/0x18c dev_hard_start_xmit+0x74/0xc0 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Corrección de UAF en la desvinculación de sva con IOPF pendientes. El commit 17fce9d2336d ("iommu/vt-d: Colocar la habilitación de iopf en la ruta de conexión del dominio") deshabilita IOPF en el dispositivo eliminándolo de la cola de IOPF de su IOMMU cuando el último dominio con capacidad para IOPF se desvincula del dispositivo. Desafortunadamente, esto se realizó en un lugar incorrecto donde aún hay IOPF pendientes. Como resultado, se puede generar un error de use-after-free y, finalmente, un pánico del kernel con un seguimiento del kernel similar al siguiente: refcount_t: underflow; use-after-free. ADVERTENCIA: CPU: 3 PID: 313 en lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0 Cola de trabajo: iopf_queue/dmar0-iopfq iommu_sva_handle_iopf Rastreo de llamadas: iopf_free_group+0xe/0x20 process_one_work+0x197/0x3d0 worker_thread+0x23a/0x350 ? rescuer_thread+0x4a0/0x4a0 kthread+0xf8/0x230 ? finish_task_switch.isra.0+0x81/0x260 ? kthreads_online_cpu+0x110/0x110 ? kthreads_online_cpu+0x110/0x110 ret_from_fork+0x13b/0x170 ? kthreads_online_cpu+0x110/0x110 ret_from_fork_asm+0x11/0x20 ---[ end trace 0000000000000000 ]--- La función intel_pasid_tear_down_entry() se encarga de impedir que el hardware genere nuevos fallos de página y de eliminar todos los que se están ejecutando. Por lo tanto, mover iopf_for_domain_remove() después de esta función debería resolver este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen: corrección de UAF en dmabuf_exp_from_pages() [dma_buf_fd() corrige; no hay preferencias sobre el árbol que recorre - depende de los usuarios de xen]. En cuanto insertamos una referencia a un archivo en la tabla de descriptores, otro hilo podría cerrarla. Esto funciona bien cuando solo devolvemos ese descriptor al espacio de usuario (es una ejecución, pero es una ejecución de espacio de usuario y el kernel no puede hacer nada al respecto). Sin embargo, si después de fd_install() accedemos a objetos que se destruirían al cerrar (ya sea el propio archivo de estructura o cualquier objeto destruido por su ->release()), tenemos un UAF. dma_buf_fd() combina la reserva de un descriptor con fd_install(). gntdev dmabuf_exp_from_pages() lo llama y procede a acceder a los objetos destruidos al cerrar, empezando por el propio gntdev_dmabuf. Arregle esto reservando el descriptor antes de cualquier otra cosa y ejecutando fd_install() solo cuando todo esté configurado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panthor: Corrección de UAF en el código de debugfs de panthor_gem_create_with_handle(). Es posible que el objeto ya se haya eliminado después de drm_gem_object_put(). En general, el objeto debería estar completamente construido antes de llamar a drm_gem_handle_create(), excepto que el seguimiento de debugfs utiliza un bloqueo, una lista y un indicador independientes para indicar si el objeto se ha inicializado. Dado que estoy trabajando en todo esto, se simplifica añadiendo el objeto a debugfs solo cuando esté listo, lo que nos permite eliminar ese indicador. panthor_gem_debugfs_bo_rm() ya comprueba si se nos ha añadido a la lista o si se trata de una limpieza de la ruta de error. v2: Corrección de problemas de compilación para !CONFIG_DEBUGFS (Adrián). v3: Añadir salto de línea y eliminar comentario obsoleto (Liviu).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/rockchip: vop2: falla correctamente si falta un plano principal para un puerto de vídeo. Cada ventana de un vop2 es utilizable por un conjunto específico de puertos de vídeo, por lo que al vincular el vop2, revisamos la lista de ventanas disponibles intentando encontrar una designada como plano principal y utilizable por ese puerto específico. Posteriormente, el código quiere usar drm_crtc_init_with_planes con ese plano principal encontrado, pero hasta ahora no se ha comprobado si realmente se encontró un plano principal. Por alguna razón, el vp2 rk3576 no tiene una ventana principal utilizable (si vp0 también está en uso), lo que sacó a la luz el problema y terminó en una desreferencia de puntero nulo más adelante. Como esperamos que exista un plano principal para un puerto de vídeo, agregue una comprobación al final de la iteración de la ventana y falle el sondeo si no se encuentra ninguno.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrección del use-after-free en amdgpu_userq_suspend+0x51a/0x5a0 [ +0.000020] ERROR: KASAN: slab-use-after-free in amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000817] Read of size 8 at addr ffff88812eec8c58 by task amd_pci_unplug/1733 [ +0.000027] CPU: 10 UID: 0 PID: 1733 Comm: amd_pci_unplug Tainted: G W 6.14.0+ #2 [ +0.000009] Tainted: [W]=WARN [ +0.000003] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000004] Call Trace: [ +0.000004] [ +0.000003] dump_stack_lvl+0x76/0xa0 [ +0.000011] print_report+0xce/0x600 [ +0.000009] ? srso_return_thunk+0x5/0x5f [ +0.000006] ? kasan_complete_mode_report_info+0x76/0x200 [ +0.000007] ? kasan_addr_to_slab+0xd/0xb0 [ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000707] kasan_report+0xbe/0x110 [ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000541] __asan_report_load8_noabort+0x14/0x30 [ +0.000005] amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000535] ? stop_cpsch+0x396/0x600 [amdgpu] [ +0.000556] ? stop_cpsch+0x429/0x600 [amdgpu] [ +0.000536] ? __pfx_amdgpu_userq_suspend+0x10/0x10 [amdgpu] [ +0.000536] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? kgd2kfd_suspend+0x132/0x1d0 [amdgpu] [ +0.000542] amdgpu_device_fini_hw+0x581/0xe90 [amdgpu] [ +0.000485] ? down_write+0xbb/0x140 [ +0.000007] ? __mutex_unlock_slowpath.constprop.0+0x317/0x360 [ +0.000005] ? __pfx_amdgpu_device_fini_hw+0x10/0x10 [amdgpu] [ +0.000482] ? __kasan_check_write+0x14/0x30 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? up_write+0x55/0xb0 [ +0.000007] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? blocking_notifier_chain_unregister+0x6c/0xc0 [ +0.000008] amdgpu_driver_unload_kms+0x69/0x90 [amdgpu] [ +0.000484] amdgpu_pci_remove+0x93/0x130 [amdgpu] [ +0.000482] pci_device_remove+0xae/0x1e0 [ +0.000008] device_remove+0xc7/0x180 [ +0.000008] device_release_driver_internal+0x3d4/0x5a0 [ +0.000007] device_release_driver+0x12/0x20 [ +0.000004] pci_stop_bus_device+0x104/0x150 [ +0.000006] pci_stop_and_remove_bus_device_locked+0x1b/0x40 [ +0.000005] remove_store+0xd7/0xf0 [ +0.000005] ? __pfx_remove_store+0x10/0x10 [ +0.000006] ? __pfx__copy_from_iter+0x10/0x10 [ +0.000006] ? __pfx_dev_attr_store+0x10/0x10 [ +0.000006] dev_attr_store+0x3f/0x80 [ +0.000006] sysfs_kf_write+0x125/0x1d0 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? __kasan_check_write+0x14/0x30 [ +0.000005] kernfs_fop_write_iter+0x2ea/0x490 [ +0.000005] ? rw_verify_area+0x70/0x420 [ +0.000005] ? __pfx_kernfs_fop_write_iter+0x10/0x10 [ +0.000006] vfs_write+0x90d/0xe70 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? __pfx_vfs_write+0x10/0x10 [ +0.000004] ? local_clock+0x15/0x30 [ +0.000008] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_slab_free+0x5f/0x80 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? fdget_pos+0x1d3/0x500 [ +0.000007] ksys_write+0x119/0x220 [ +0.000005] ? putname+0x1c/0x30 [ +0.000006] ? __pfx_ksys_write+0x10/0x10 [ +0.000007] __x64_sys_write+0x72/0xc0 [ +0.000006] x64_sys_call+0x18ab/0x26f0 [ +0.000006] do_syscall_64+0x7c/0x170 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __pfx___x64_sys_openat+0x10/0x10 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? fpregs_assert_state_consistent+0x21/0xb0 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? syscall_exit_to_user_mode+0x4e/0x240 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? do_syscall_64+0x88/0x170 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? irqentry_exit+0x43/0x50 [ +0.000004] ? srso_return_thunk+0x5 ---truncado---