Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4: Evitar la desreferencia de puntero NULL en nfs42_complete_copies() En el nodo de un cliente NFS, algunos archivos guardados en el punto de montaje del servidor NFS se copiaron a otra ubicación del mismo servidor NFS. Accidentalmente, nfs42_complete_copies() tuvo un fallo por desreferencia de puntero NULL con el siguiente syslog: [232064.838881] NFSv4: la recuperación de estado falló para el archivo abierto nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: la recuperación de estado falló para el archivo abierto nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] No se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000058 [232066.588586] Información de cancelación de memoria: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (EL actual), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: error de traducción de nivel 3 [232066.589559] Información de cancelación de datos: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] usuario pgtable: 64k páginas, VA de 48 bits, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=000000000000000 [232066.590757] Error interno: Oops: 96000007 [#1] SMP [232066.590958] Módulos vinculados en: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport conjunto de ip ficticio ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp enlace tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter puente stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: cargado No contaminado 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Nombre del hardware: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] estado de la página: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] equipo: nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] estado de la página: nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] servidor de arranque: ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: 0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.6001---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbcon: soluciona un problema de desreferencia de puntero NULL en fbcon_putcs syzbot ha encontrado un error de desreferencia de puntero NULL en fbcon. Aquí está el reproductor C simplificado: struct param { uint8_t type; struct tiocl_selection ts; }; int main() { struct fb_con2fbmap con2fb; struct param param; int fd = open("/dev/fb1", 0, 0); con2fb.console = 0x19; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); param.type = 2; param.ts.xs = 0; param.ts.ys = 0; param.ts.xe = 0; param.ts.ye = 0; param.ts.sel_mode = 0; int fd1 = open("/dev/tty1", O_RDWR, 0); ioctl(fd1, TIOCLINUX, &param); con2fb.console = 1; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); devolver 0; } Después de llamar a ioctl(fd1, TIOCLINUX, &param), el ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) subsiguiente hace que el núcleo siga una ruta de ejecución diferente: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Dado que ops->putcs es un puntero NULL, esto lleva a un pánico del núcleo. Para evitar esto, necesitamos llamar a set_blitting_type() dentro de set_con2fb_map() para inicializar correctamente ops->putcs.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Verificar puntero nulo antes de desreferenciar se [QUÉ Y CÓMO] se verificó como nulo previamente en la misma función, lo que indica que podría ser nulo; por lo tanto, se debe verificar cuando se vuelva a utilizar. Esto soluciona 1 problema FORWARD_NULL informado por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: proteger uart_port_dtr_rts() en uart_shutdown() también El commit af224ca2df29 (serial: core: Prevenir el acceso inseguro al puerto uart, parte 3) agregó algunas comprobaciones uport == NULL. Agregó una a uart_shutdown(), por lo que el commit asume que uport puede ser NULL allí. Pero justo después de esa protección, hay una llamada "uart_port_dtr_rts(uport, false);" sin protección. Eso se invoca solo si HUPCL está configurado, por lo que supongo que esa es la razón por la que no vemos muchos de estos informes. O no puede ser NULL en este punto en absoluto por alguna razón :P. Hasta que se investigue lo anterior, manténgase del lado seguro y mueva esta desreferencia al if también. Obtuve esta inconsistencia de Coverity bajo CID 1585130. Gracias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thermal: core: copia libre de tzp junto con la zona térmica. Aún se puede acceder al objeto al que apunta tz->tzp después de liberarlo en thermal_zone_device_unregister(), por lo que debe mover su liberación al punto después de que se haya completado la eliminación en el que ya no se pueda acceder a él.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thermal: core: recuento de referencia de la zona en thermal_zone_get_by_id() Hay lugares en el código de netlink térmico donde nada impide que el objeto de zona térmica desaparezca mientras se accede a él después de que thermal_zone_get_by_id() lo haya devuelto. Para solucionar esto, haga que thermal_zone_get_by_id() obtenga una referencia en el objeto de dispositivo de zona térmica que se devolverá con la ayuda de get_device(), bajo thermal_list_lock, y ajuste todos sus llamadores a este cambio con la ayuda de la infraestructura cleanup.h.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_conn: Fix UAF en hci_enhanced_setup_sync Esto verifica si la conexión ACL sigue siendo válida, ya que podría destruirse mientras hci_enhanced_setup_sync está pendiente de cmd_sync, lo que genera el siguiente seguimiento: ERROR: KASAN: slab-use-after-free en hci_enhanced_setup_sync+0x91b/0xa60 Lectura de tamaño 1 en la dirección ffff888002328ffd por la tarea kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 No contaminado 6.11.0-rc6-01300-g810be445d8d6 #7099 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 01/04/2014 Cola de trabajo: hci0 hci_cmd_sync_work Seguimiento de llamadas: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? asignar_trabajo+0x167/0x240 subproceso_trabajador+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? Asignado por la tarea 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entrada_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_de_la_bifurcación+0x2f/0x70 ret_de_la_bifurcación_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/ct: evitar UAF en send_recv() Asegurarnos de que serializamos con el lado de finalización para evitar que UAF con valla salga del ámbito en la pila, ya que no tenemos ni idea de si se activará después del tiempo de espera antes de que podamos borrar del xa. También tenemos algunas cargas y almacenamientos dependientes para los que necesitamos el orden correcto, y carecemos de las barreras necesarias. Arregla esto tomando el ct->lock después de la espera, que también está retenido por el lado de finalización. v2 (Badal): - También se imprime después de adquirir el bloqueo y ver el tiempo de espera. (seleccionado de el commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcu/nocb: Se ha corregido la activación de rcuog desde un softirq sin conexión. Después de que una CPU se haya desconectado y antes de que finalmente llame a rcutree_report_cpu_dead(), aún hay oportunidades para que se pongan en cola devoluciones de llamadas, por ejemplo, desde un softirq. Cuando eso sucede en NOCB, la activación de rcuog se pospone a través de una IPI a una CPU en línea para no llamar al programador y correr el riesgo de armar el ancho de banda RT después de que los temporizadores hr se hayan migrado y deshabilitado. Pero realizar una IPI sincronizada desde un softirq tiene errores, como se informa en el siguiente escenario: ADVERTENCIA: CPU: 1 PID: 26 en kernel/smp.c:633 smp_call_function_single Módulos vinculados en: rcutorture torture CPU: 1 UID: 0 PID: 26 Comm: immigration/1 No contaminado 6.11.0-rc1-00012-g9139f93209d1 #1 Detenedor: multi_cpu_stop+0x0/0x320 <- __stop_cpus+0xd0/0x120 RIP: 0010:smp_call_function_single swake_up_one_online __call_rcu_nocb_wake __call_rcu_common ? rcu_torture_one_read call_timer_fn __run_timers run_timer_softirq handle_softirqs irq_exit_rcu ? tick_handle_periodic sysvec_apic_timer_interrupt Solucione esto forzando la activación diferida de rcuog a través del temporizador NOCB cuando la CPU esté fuera de línea. La activación real se realizará desde rcutree_report_cpu_dead().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: corrige la falta de icsk_syn_mss con IPPROTO_SMC Eric informa un pánico en IPPROTO_SMC y proporciona los hechos de que cuando se configura INET_PROTOSW_ICSK, también se debe configurar icsk->icsk_sync_mss. Error: No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000000 Información de aborto de memoria: ESR = 0x0000000086000005 EC = 0x21: IABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: error de traducción de nivel 1 usuario pgtable: 4k páginas, VA de 48 bits, pgdp=00000001195d1000 [000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=000000000000000 Error interno: Oops: 0000000086000005 [#1] Módulos PREEMPT SMP vinculados en: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 No contaminado 6.11.0-rc7-syzkaller-g5f5673607153 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9: 1fffe0001b16f0f1 x8: 0000000000000000 x7: 0000000000000000 x6: 000000000000003f x5: 0000000000000040 x4 : 00000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Rastreo de llamadas: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 seguridad/seguridad.c:4425 __sock_create+0x4c8/0x884 red/socket.c:1587 sock_create red/socket.c:1622 [en línea] __sys_socket_create red/socket.c:1659 [en línea] __sys_socket+0x134/0x340 red/socket.c:1706 __do_sys_socket red/socket.c:1720 [en línea] __se_sys_socket red/socket.c:1718 [en línea] __arm64_sys_socket+0x7c/0x94 red/socket.c:1718 __invoke_syscall arch/arm64/kernel/syscall.c:35 [en línea] invocar_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+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Código: ???????? ???????? ???????? ???????? (????????) ---[ fin del seguimiento 0000000000000000 ]--- Este parche agrega una implementación de juguete que realiza un retorno simple para evitar tal pánico. Esto se debe a que MSS se puede configurar en sock_create_kern o smc_setsockopt, de manera similar a como se hace en AF_SMC. Sin embargo, para AF_SMC, actualmente no hay forma de sincronizar MSS dentro de __sys_connect_file. Esta implementación de juguete sienta las bases para que admitamos dicha función para IPPROTO_SMC en el futuro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/fbdev-dma: Solo limpiar la E/S diferida si es necesario el commit 5a498d4d06d6 ("drm/fbdev-dma: Solo instalar la E/S diferida si es necesario") inicializa la E/S diferida solo si se usa. Sin embargo, drm_fbdev_dma_fb_destroy() llama a fb_deferred_io_cleanup() incondicionalmente con struct fb_info.fbdefio == NULL. KASAN con el controlador de pantalla de silicio de Apple fuera del árbol publica la siguiente advertencia de __flush_work() de una estructura aleatoria work_struct en lugar de las derefs de puntero NULL esperadas. [ 22.053799] ------------[ cortar aquí ]------------ [ 22.054832] ADVERTENCIA: CPU: 2 PID: 1 en kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Módulos vinculados en: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow No contaminado 6.11.2-asahi+ #asahi-dev [ 22.075612] Nombre del hardware: Apple MacBook Pro (13 pulgadas, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ [22.080345] sp: ffffc000836ef820 [22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [22.082678] x26: dfffc0000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [22.084263] x23: ffff80004b7862b8 x22: dfffc0000000000 x21: ffff80005aa1d470 [22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9: 1ffff800106ddf0e [22.092206] x8: 0000000000000000 x7: aaaaaaaaaaaaaaaa x6: 0000000000000001 [22.093790] x5: 00836ef728 x4: 0000000000000000 x3: 0000000000000020 [22.095368] x2: 00000000000000008 x1: 00000000000000aa x0: 00000000000000000 [ 22.096955] Rastreo de llamadas: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] anular registro de búfer de fotogramas+0x210/0x2f0 [ 22.102575] drm_fb_helper_anular registro de información+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] apagado_dispositivo+0x368/0x4d8 [ 22.112095] reinicio_kernel+0x6c/0x1d0 [ 22.112946] reinicio_del_sistema_arm64+0x1c8/0x328 [ 22.113868] invocar_llamada_al_sistema+0x78/0x1a8 [ 22.114703] hacer_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] controlador_sincronización_el0t_64+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Detener el perfmon activo antes de ser destruido Al ejecutar `kmscube` con uno o más monitores de rendimiento habilitados a través de `GALLIUM_HUD`, puede ocurrir el siguiente pánico del kernel: [ 55.008324] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 00000000052004a4 [ 55.008368] Información de aborto de memoria: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (EL actual), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: error de traducción de nivel 1 [ 55.008434] Información de interrupción de datos: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] pgtable de usuario: páginas de 4k, VA de 39 bits, pgdp=00000001046c6000 [ 55.008497] [000000000052004a4] pgd=0000000000000000, p4d=00000000000000000, pud=0000000000000000 [ 55.008525] Error interno: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Módulos vinculados en: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Contaminado: GC 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Nombre del hardware: Raspberry Pi 4 Modelo B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9: ffffffda1bd04d04 [55.011162] x8: ffffff8102097b80 x7: 0000000000000000 x6: 00000000030a5857 [55.011880] x5: 00ffffffffffffff x4: 0300000005200470 x3: 0300000005200470 [55.012598] x2: ffffff8101238000 x1: 0000000000000021 x0 : 0300000005200470 [ 55.013292] Rastreo de llamadas: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Código: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ fin del seguimiento 000000000000000 ]--- [ 55.020411] nota: v3d_bin[166] salió con preempt_count 1 Este problema surge porque, al cerrar el descriptor de archivo (lo que sucede cuando interrumpimos `kmscube`), el monitor de rendimiento activo no se detiene. Aunque todos los monitores de rendimiento se destruyen en `v3d_perfmon_close_file()`, el puntero del monitor de rendimiento activo (`v3d->active_perfmon`) aún se conserva. Si se ejecuta de nuevo `kmscube`, el controlador intentará detener el monitor de rendimiento activo utilizando el puntero obsoleto en `v3d->active_perfmon`. Sin embargo, este puntero ya no es válido porque el proceso anterior ya ha finalizado y todos los monitores de rendimiento asociados con él se han destruido y liberado. Para solucionar esto, cuando el monitor de rendimiento activo pertenece a un proceso determinado, deténgalo explícitamente antes de destruirlo y liberarlo.