Vulnerabilidades

Se encontró una vulnerabilidad en Tenda AC500 2.0.1.9(1307). Ha sido calificada como crítica. Este problema afecta a la función formSetCfm del archivo /goform/setcfm. La manipulación del argumento funcpara1 provoca un desbordamiento de búfer en la región stack de la memoria. El ataque puede iniciarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador asociado de esta vulnerabilidad es VDB-261143. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf: RISCV: no se desea corregir el pánico en el controlador de desbordamiento de pmu (1 << idx) de int al configurar bits en overflowed_ctrs largos sin firmar; use BIT() en su lugar. Este pánico ocurre cuando se ejecuta 'perf record -e sucursales' en sophgo sg2042. [273.311852] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000098 [273.320851] Ups [#1] [273.323179] Módulos vinculados en: [273.326303] CPU: 0 PID: 1475 Comm: perf No contaminado 6.6.0- rc3+#9 [ 273.332521] Nombre de hardware: Sophgo Mango (DT) [ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e [ 273.347091] epc : ffff80aecd98 ra: ffffffff80aee056 sp: ffffff6e36928b0 [273.354454] gp: ffffffff821f82d0 tp : ffffffd90c353200 T0: 0000002ade4f9978 [273.361815] T1: 000000000000504D55 T2: FFFFFFFF8016CD8C S0: FFFFFFF66E3692A70 [273.369180] 1A8E81800000 [273.376540] A2: 0000003C00070198 A3: 0000003C00DB75A4 A4: 000000000000000015 [273.383901] A5: FFFFFFD7FF8804B0 A6: 0000000000000015 a7: 000000000000002a [273.391327] s2: 000000000000ffff s3: 0000000000000000 s4: ffffffd7ff8803b0 [273.398773] s5: 0000000000504d55 s6: ffffffd905069800 s7: ffffffff821fe210 [273.406139] s8: 000000007ffffff s9: ffffffd7ff8803b0 s10: ffffffd903f29098 [273.413660] s11: 00080000000 t3: 0000000000000003 t4: ffffffff8017a0ca [273.421022] t5: ffffffff8023cfc2 t6: ffffffd9040780e8 [273.426437] estado: 0000000200000100 badaddr: 0000000000000098 causa: 00000d [ 273.434512] [] riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.441169] [] handle_percpu_devid_irq+0x98/0x1ee [ 273.447562 ] [] generic_handle_domain_irq+0x28/0x36 [ 273.454151] [] riscv_intc_irq+0x36/0x4e [ 273.459659] [] 0x4a/0x74 [ 273.465442] [] do_irq+0x62/0x92 [ 273.470360] Código: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783 [ 273.477921] ---[ final de seguimiento 0000000000000000 ]--- 273.482 630] Pánico del kernel: no se sincroniza: excepción fatal en la interrupción

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: rfcomm: corrija null-ptr-deref en rfcomm_check_security Durante nuestras pruebas preliminares del proceso de conexión y desconexión en la capa RFCOMM, descubrimos este error. Comparando los paquetes de un proceso normal de conexión y desconexión con el caso de prueba que desencadenó un informe KASAN. Analizamos la causa de este error de la siguiente manera: 1. En los paquetes capturados durante una conexión normal, el host envía un paquete `HCI_CMD` del tipo `Read Encryption Key Size` (código de operación de comando: 0x1408) al controlador para consultar la longitud. de clave de cifrado. Después de recibir este paquete, el controlador responde inmediatamente con un paquete de comando completo (código de evento: 0x0e) para devolver el tamaño de la clave de cifrado. 2. En nuestro caso de prueba fuzz, el tiempo de respuesta del controlador a este paquete se retrasó hasta un punto inesperado: después de que las capas RFCOMM y L2CAP se desconectaran, pero antes de que se desconectara la capa HCI. 3. Después de recibir la respuesta del tamaño de la clave de cifrado en el momento descrito en el punto 2, el host aún llamó a la función rfcomm_check_security. Sin embargo, en ese momento `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;` ya se había lanzado, y cuando se ejecutó la función `return hci_conn_security(conn->hcon, d->sec_level, auth_type, d ->out);`, específicamente al acceder a `conn->hcon`, ocurrió un error null-ptr-deref. Para corregir este error, verifique si `sk->sk_state` está BT_CLOSED antes de llamar a rfcomm_recv_frame en rfcomm_process_rx.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la carrera de datos en btrfs_use_block_rsv() al acceder a la reserva de bloque En btrfs_use_block_rsv() leemos el tamaño de una reserva de bloque sin bloquear su spinlock, lo que hace que KCSAN se queje porque el tamaño de una reserva de bloque siempre se actualiza mientras se mantiene su bloqueo de giro. El informe de KCSAN es el siguiente: [653.313148] ERROR: KCSAN: data-race en btrfs_update_delayed_refs_rsv [btrfs] / btrfs_use_block_rsv [btrfs] [653.314755] leído en 0x000000017f5871b8 de 8 bytes por tarea 7519 en 0: [653.314779] btrfs_use_block_rsv+0xe4 /0x2f8 [btrfs] [653.315606] btrfs_alloc_tree_block+0xdc/0x998 [btrfs] [653.316421] btrfs_force_cow_block+0x220/0xe38 [btrfs] [653.317242] 8 [btrfs] [653.318060] btrfs_search_slot+0xda2/0x19b8 [btrfs] [ 653.318879] btrfs_del_csums+0x1dc/0x798 [btrfs] [653.319702] __btrfs_free_extent.isra.0+0xc24/0x2028 [btrfs] [653.320538] __btrfs_run_delayed_refs+0xd3c/0x 2390 [btrfs] [653.321340] btrfs_run_delayed_refs+0xae/0x290 [btrfs] [653.322140] flush_space+0x5e4/0x718 [btrfs] [653.322958] btrfs_preempt_reclaim_metadata_space+0x102/0x2f8 [btrfs] [653.323781] Process_one_work+0x3b6/0x838 [653.323800] trabajador_thread+0x75e/0xb1 0 [653.323817] kthread+0x21a/0x230 [653.323836] __ret_from_fork+0x6c/ 0xb8 [653.323855] ret_from_fork+0xa/0x30 [653.323887] escribe en 0x000000017f5871b8 de 8 bytes por tarea 576 en la CPU 3: [653.323906] [btrfs] [653.324699] btrfs_add_delayed_data_ref+0x468/0x6d8 [btrfs] [653.325494] btrfs_free_extent+0x76/0x120 [btrfs] [653.326280] __btrfs_mod_ref+0x6a8/0x6b8 [btrfs] [653.327064] btrfs_dec_ref+0x50/0x70 [btrfs] [653.327849] 236/0xa50 [btrfs] [653.328633] walk_up_tree+0x21c/0x448 [ btrfs] [653.329418] btrfs_drop_snapshot+0x802/0x1328 [btrfs] [653.330205] btrfs_clean_one_deleted_snapshot+0x184/0x238 [btrfs] [653.330995] clean_kthread+0x2b0/0x2f0 [ btrfs] [653.331781] kthread+0x21a/0x230 [653.331800] __ret_from_fork+0x6c/ 0xb8 [653.331818] ret_from_fork+0xa/0x30 Entonces agregue un ayudante para obtener el tamaño de una reserva de bloque mientras mantiene el bloqueo. Se utiliza la lectura del campo mientras se mantiene presionado el candado en lugar de usar la anotación data_race() para evitar el desgarro de la carga.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: btrfs: corrige carreras de datos al acceder a la cantidad reservada de reservas de bloque En space_info.c tenemos varios lugares donde accedemos al campo ->reserved de una reserva de bloque sin tomar la reserva de bloque spinlock primero, lo que hace que KCSAN advierta sobre una carrera de datos ya que ese campo siempre se actualiza mientras se mantiene el spinlock. Los informes de KCSAN son como los siguientes: [117.193526] ERROR: KCSAN: data-race en btrfs_block_rsv_release [btrfs] / need_preemptive_reclaim [btrfs] [117.195148] leído en 0x000000017f587190 de 8 bytes por la tarea 6303 en la CPU 3 [117.19: 5172] necesidad_preemptive_reclaim+ 0x222/0x2f0 [btrfs] [117.195992] __reserve_bytes+0xbb0/0xdc8 [btrfs] [117.196807] btrfs_reserve_metadata_bytes+0x4c/0x120 [btrfs] [117.197620] 78/0xa8 [btrfs] [117.198434] btrfs_delayed_update_inode+0x154/0x368 [btrfs] [117.199300] btrfs_update_inode+0x108/0x1c8 [btrfs] [117.200122] btrfs_dirty_inode+0xb4/0x140 [btrfs] [117.200937] btrfs_update_time+0x8c/0xb0 [btrfs] 754] touch_atime+0x16c/0x1e0 [117.201789] filemap_read+0x674/0x728 [ 117.201823] btrfs_file_read_iter+0xf8/0x410 [btrfs] [117.202653] vfs_read+0x2b6/0x498 [117.203454] ksys_read+0xa2/0x150 [117.203473] x68/0x88 [117.203495] do_syscall+0x1c6/0x210 [117.203517] __do_syscall+0xc8/0xf0 [117.203539] system_call+0x70/0x98 [117.203579] escribe en 0x000000017f587190 de 8 bytes por tarea 11 en la CPU 0: [117.203604] btrfs_block_rsv_release+0x2e8/0x578 [btrfs] 32] btrfs_delayed_inode_release_metadata+0x7c/0x1d0 [btrfs] [117.205259] __btrfs_update_delayed_inode +0x37c/0x5e0 [btrfs] [117.206093] btrfs_async_run_delayed_root+0x356/0x498 [btrfs] [117.206917] btrfs_work_helper+0x160/0x7a0 [btrfs] [117.207738] 6/0x838 [117.207768] hilo_trabajador+0x75e/0xb10 [117.207797] khilo+ 0x21a/0x230 [117.207830] __ret_from_fork+0x6c/0xb8 [117.207861] ret_from_fork+0xa/0x30 Entonces agregue un ayudante para obtener la cantidad reservada de una reserva de bloque mientras mantiene el bloqueo. Es posible que el valor ya no esté actualizado cuando lo usan need_preemptive_reclaim() y btrfs_preempt_reclaim_metadata_space(), pero está bien ya que lo peor que puede hacer es provocar que se realice más trabajo de recuperación más temprano que tarde. Se utiliza la lectura del campo mientras se mantiene presionado el candado en lugar de usar la anotación data_race() para evitar el desgarro de la carga.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/mm: no permitir la lectura de la página vsyscall para copy_from_kernel_nofault() Al intentar usar copy_from_kernel_nofault() para leer la página vsyscall a través de un programa bpf, se informó lo siguiente: ERROR: no se puede manejar el error de página para la dirección: ffffffffff600000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0 Ups: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) ...... RIP: 0010:copy_from_kernel_nofault+0x6f/0x110... ... Seguimiento de llamadas: ? copy_from_kernel_nofault+0x6f/0x110 bpf_probe_read_kernel+0x1d/0x50 bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d trace_call_bpf+0xc5/0x1c0 perf_call_bpf_enter.isra.0+0x69/0xb 0 perf_syscall_enter+0x13e/0x200 syscall_trace_enter+0x188/0x1c0 do_syscall_64+0xb5/0xe0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 < /TASK> ...... ---[ end trace 0000000000000000 ]--- Ups se activa cuando: 1) Un programa bpf usa bpf_probe_read_kernel() para leer desde la página vsyscall e invoca copy_from_kernel_nofault() que a su vez llama __get_user_asm(). 2) Debido a que la dirección de la página vsyscall no se puede leer desde el espacio del kernel, se activa una excepción de error de página en consecuencia. 3) handle_page_fault() considera la dirección de la página vsyscall como una dirección de espacio de usuario en lugar de una dirección de espacio de kernel. Esto da como resultado que no se aplique la configuración de reparación mediante bpf y se invoque page_fault_oops() debido a SMAP. Teniendo en cuenta que handle_page_fault() ya ha considerado la dirección de la página vsyscall como una dirección de espacio de usuario, solucione el problema no permitiendo la lectura de la página vsyscall para copy_from_kernel_nofault().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/mlx5: corrige la advertencia de fuente de fortify al acceder al segmento Eth ------------[ cortar aquí ]---------- -- memcpy: se detectó escritura que abarca todos los campos (tamaño 56) de un solo campo "eseg->inline_hdr.start" en /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/ wr.c:131 (tamaño 2) ADVERTENCIA: CPU: 0 PID: 293779 en /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+ 0x191b/0x1a60 [mlx5_ib] Módulos vinculados en: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) ) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd gracia sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover disquete de conmutación por error [última descarga : mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Contaminado: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Nombre de hardware: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Código: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11 : 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) 63a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 00000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? show_regs+0x72/0x90? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __advertir+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0? handle_bug+0x46/0x90? exc_invalid_op+0x19/0x80? asm_exc_invalid_op+0x1b/0x20? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] 8e/0x1e0 ? validar_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 _push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/xen: agregue alguna verificación de puntero nulo a smp.c kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free Una serie reciente de DRM que pretende simplificar el soporte para "puentes transparentes" y el manejo de aplazamientos de sonda expuso irónicamente un uso posterior -Problema gratuito en el aplazamiento de la sonda pmic_glink_altmode. Esto se ha manifestado como que el subsistema de visualización ocasionalmente falla al inicializarse y se eliminan las referencias del puntero NULL durante el arranque de máquinas como la Lenovo ThinkPad X13s. Específicamente, el puente dp-hpd actualmente está registrado antes de que se hayan adquirido todos los recursos, lo que significa que también se puede cancelar su registro en caso de aplazamientos de sonda. Mientras tanto, hay una ventana de carrera donde el nuevo controlador del puente auxiliar (o el controlador PHY anteriormente) puede haber buscado el puente dp-hpd y almacenado un puntero (sin recuento de referencias) al puente que está a punto de ser desasignado. Cuando el controlador de pantalla se inicializa posteriormente, esto activa un use-after-free al conectar los puentes: dp -> aux -> dp-hpd (liberado) que puede, por ejemplo, provocar que el puente liberado no se pueda conectar: [drm :drm_bridge_attach [drm]] *ERROR* no se pudo adjuntar el puente /soc@0/phy@88eb000 al codificador TMDS-31: -16 o una desreferencia de puntero NULL: no se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000000... Seguimiento de llamadas: drm_bridge_attach+0x70/0x1a8 [drm] drm_aux_bridge_attach+0x24/0x38 [aux_bridge] drm_bridge_attach+0x80/0x1a8 [drm] dp_bridge_init+0xa8/0x15c [msm] msm_dp_modeset_init+0x28/0xc4 [msm] El puente DRM la implementación es claramente frágil e implícitamente construido sobre el supuesto de que es posible que los puentes nunca desaparezcan. En este caso, la solución es mover el registro del puente en el controlador pmic_glink_altmode después de que se hayan buscado todos los recursos. Por cierto, con la nueva implementación del puente dp-hpd, que registra dispositivos secundarios, esto también es un requisito debido a un problema de larga data en el núcleo del controlador que, de lo contrario, puede provocar un bucle de aplazamiento de la sonda (consulte el compromiso fbc35b45f9f6 ("Agregar documentación sobre el significado de -EPROBE_DEFER")). [DB: mensaje de confirmación ligeramente corregido agregando la palabra 'compromiso']

Se encontró una vulnerabilidad en Tenda AC500 2.0.1.9(1307). Ha sido clasificada como crítica. Esto afecta a la función R7WebsSecurityHandler del archivo /goform/execCommand. La manipulación del argumento contraseña provoca un desbordamiento de búfer en la región stack de la memoria. Es posible iniciar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. A esta vulnerabilidad se le asignó el identificador VDB-261141. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

Se encontró una vulnerabilidad en Tenda AC500 2.0.1.9(1307). Ha sido declarada crítica. Esta vulnerabilidad afecta a la función formQuickIndex del archivo /goform/QuickIndex. La manipulación del argumento PPPOEPassword provoca un desbordamiento de búfer en la región stack de la memoria. El ataque se puede iniciar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. VDB-261142 es el identificador asignado a esta vulnerabilidad. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: soluciona el fallo del kernel cuando se recibe 1588 en dispositivos HIP08 Los dispositivos HIP08 no registran los dispositivos ptp, por lo que hdev->ptp es NULL, pero el hardware puede recibir 1588 y configure el bit HNS3_RXD_TS_VLD_B, por lo que, si coincide con este caso, el acceso a hdev->ptp->flags provocará una falla del kernel: [5888.946472] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000018 [5888.946475] No se puede para manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000018 ... [ 5889.266118 ] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 ge] [5889.279101] sp: ffff800012c3bc50 [5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24 : ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [5889.340965] x11: bbfeff4d22000000 x10: 00000000000000000 [5889.347303] x9: ffff8000094021 24 x8: 0200f78811dfbb4d [5889.353637] x7: 2200000000191b01 x6: FFFF208002A7D480 [5889.359959] x5: 000000000000000000 X4: 0000000000000000 [5889.366271] x3: 0000000000000000 X2: 00000000000000000000000000000000000000000000000000 ABRIBA 80 [5889.378857] Lista de llamada: [5889.382285] HCLGE_PTP_GET_RX_HWTS+0x40/0x170 [HCLGE] [5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3] [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3] [ 0] hns3_nic_common_poll+0xa8/0x220 [hns3] [ 5889.411084] napi_poll+0xcc/0x264 [ 5889.415329] net_rx_action+0xd4/0x21c [ 5889.419911] __do_softirq+0x130/0x358 [ 5889.424484] irq_exit+0x134/0x154 [ 5889.428700] 0xf0 [ 5889.433684] gic_handle_irq+0x78/0x2c0 [ 5889.438319] el1_irq+0xb8/0x140 [ 5889.442354] arch_cpu_idle+0x18/0x40 [ 5889.446816] default_idle_call+0x5c/0x1c0 [ 5889.451714] cpuidle_idle_call+0x174/0x1b0 [ 5889.456692] do_idle+0xc8/0x160 [ 5889.46071 7] cpu_startup_entry+0x30/0xfc [ 5889.465523] second_start_kernel+0x158/0x1ec [ 5889.470936] Código: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [5889.477950] SMP: deteniendo las CPU secundarias [5890.514626] SMP: no se pudieron detener las CPU secundarias 0-69,71-95 [5890.522951] Iniciando el kernel de crashdump...