Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: Establecer el contexto de ejecución para la devolución de llamada de rawtp test_run syzbot informó un bloqueo cuando el programa rawtp ejecutado a través de la interfaz test_run llama al asistente bpf_get_attach_cookie o cualquier otro asistente que toque el puntero tarea->bpf_ctx. Configuración del contexto de ejecución (tarea->puntero bpf_ctx) para la devolución de llamada test_run.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ax25: corrige el desequilibrio de recuento en conexiones entrantes Al liberar un socket en ax25_release(), llamamos a netdev_put() para disminuir el recuento en el dispositivo ax.25 asociado. Sin embargo, la ruta de ejecución para aceptar una conexión entrante nunca llama a netdev_hold(). Este desequilibrio conduce a errores de recuento y, en última instancia, a fallos del kernel. Un seguimiento de llamada típico para la situación anterior comenzará con uno de los siguientes errores: refcount_t: decrement hit 0; pérdida de memoria. refcount_t: desbordamiento insuficiente; use-after-free. Y luego tendrá un seguimiento como: Call Trace: ? show_regs+0x64/0x70? __advertir+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100? report_bug+0x158/0x190? prb_read_valid+0x20/0x30? handle_bug+0x3e/0x70? exc_invalid_op+0x1c/0x70? asm_exc_invalid_op+0x1f/0x30? refcount_warn_saturate+0xb2/0x100? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] Al reiniciar (o cualquier intento de eliminar la interfaz), el kernel se atasca en un bucle infinito: unregister_netdevice: esperando ax0 para quedar libre. Recuento de uso = 0 Este parche corrige estos problemas asegurando que llamemos a netdev_hold() y ax25_dev_hold() para nuevas conexiones en ax25_accept(). Esto hace que la lógica que conduce a ax25_accept() coincida con la lógica de ax25_bind(): en ambos casos incrementamos el refcount, que finalmente disminuye en ax25_release().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: bloquear wiphy en cfg80211_get_station Wiphy debe estar bloqueado antes de llamar a rdev_get_station() (ver lockdep afirmar en ieee80211_get_station()). Esto corrige la siguiente desreferencia NULL del kernel: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000050 Información de cancelación de memoria: ESR = 0x0000000096000006 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0 , S1PTW = 0 FSC = 0x06: error de traducción de nivel 2 Información de cancelación de datos: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 tabla de páginas de usuario: 4k páginas, VA de 48 bits, pgdp=0000000003001000 [0000000000000050] 00000002dca003 , p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Error interno: Ups: 0000000096000006 [#1] Módulos SMP vinculados en: netconsole dwc3_meson_g12a dwc3_of_simple dwc 3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comunicaciones: kworker/u8 :0 No contaminado 6.4.0-02144-g565f9a3a7911-dirty #705 Nombre de hardware: RPT (r1) (DT) Cola de trabajo: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr: sta_set_sinfo+0xcc/0xbd4 sp: ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 6: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: 0294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 000000000000000 0 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9: 0000000000000000 x8: ffff000007b43d90 x7: 00 0000007a1e2125 x6: 0000000000000000 x5: ffff0000024e0900 x4: ffff800000a0250c x3: ffff000007b43c90 x2: ffff00000294ca98 x1: ffff000006831920 x0: 0000000000000000 Rastreo de llamadas: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 0211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 Process_one_work+0x1ec/ 0x414 work_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Código: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814) Esto sucede porque STA tiene tiempo para desconectarse y volver a conectarse antes de batadv_v_elp_throughput_metric_up date() se programa el trabajo retrasado. En esta situación, ath10k_sta_state() puede estar en medio de restablecer los datos de arsta cuando la cola de trabajo tiene la oportunidad de programarse y termina accediendo a ella. Bloquear Wiphy evita eso.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: mac80211: corrige el punto muerto en ieee80211_sta_ps_deliver_wakeup() La función ieee80211_sta_ps_deliver_wakeup() toma sta->ps_lock para sincronizarse con ieee80211_tx_h_unicast_ps_buf() que se llama desde el contexto softirq. Sin embargo, usar solo spin_lock() para obtener sta->ps_lock en ieee80211_sta_ps_deliver_wakeup() no impide que softirq se ejecute en esta misma CPU, ejecute ieee80211_tx_h_unicast_ps_buf() e intente tomar este mismo bloqueo que termina en punto muerto. A continuación se muestra un ejemplo de bloqueo de rcu que surge en tal situación. rcu: INFORMACIÓN: rcu_sched autodetectado bloqueo en la CPU rcu: 2-....: (42413413 marca este GP) idle=b154/1/0x40000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 santiamén g= 2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpa_supplicant Contaminado: GW 6.4.0-02158-g1b062f552873 #742 Nombre de hardware: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO - TCO -DIT -SSBS BTYPE=--) pc: queued_spin_lock_slowpath+0x58/0x2d0 lr: invoke_tx_handlers_early+0x5b4/0x5c0 sp: ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 : ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: 08c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 0000000000895440 x8: 000000000010533c x7: ffff00000ad8b740 x6: ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Rastreo de llamadas: pin_lock_slowpath+0x58/0x2d0 ieee80211_tx+0x80/0x12c ieee80211_tx_pending+0x110/0x278 tasklet_action_common.constprop.0+0x10c/0x144 tasklet_action+0x20/0x28 _stext +0x11c/0x284 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 do_softirq+0x74/0x7c __local_bh_enable_ip+0xa0/0xa4 _ieee80211_wake_txqs+0x3b0 /0x4b8 __ieee80211_wake_queue+0x12c/0x168 ieee80211_add_pending_skbs+0xec/0x138 ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480 ieee80211_mps_sta_status_update .part.0+0xd8/0x11c ieee80211_mps_sta_status_update+0x18/0x24 sta_apply_parameters+0x3bc/0x4c0 ieee80211_change_station+0x1b8/0x2dc nl80211_set_station+0x444/0x49c genl_family_rcv_ms g_doit.isra.0+0xa4/0xfc genl_rcv_msg+0x1b0/0x244 netlink_rcv_skb+0x38/0x10c genl_rcv+0x34 /0x48 netlink_unicast+0x254/0x2bc netlink_sendmsg+0x190/0x3b4 ____sys_sendmsg+0x1e8/0x218 ___sys_sendmsg+0x68/0x8c __sys_sendmsg+0x44/0x84 __arm64_sys_sendmsg+0x 20/0x28 do_el0_svc+0x6c/0xe8 el0_svc+0x14/0x48 el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x14c /0x150 El uso de spin_lock_bh()/spin_unlock_bh() en su lugar evita que softirq se active en la misma CPU que mantiene el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: difiere la exposición de anon_fd hasta que copy_to_user() tenga éxito. Después de instalar el fd anónimo, ahora podemos verlo en el área de usuario y cerrarlo. Sin embargo, en este punto es posible que no hayamos obtenido el recuento de referencias del caché, pero lo colocaremos durante colse fd, por lo que esto puede causar un UAF de caché. Así que tome el recuento de referencias de caché antes de fd_install(). Además, según la convención del kernel, el usuario se hace cargo de fd después de fd_install(), y el kernel no debe llamar a close_fd() después de eso, es decir, debe llamar a fd_install() después de que todo esté listo, por lo que fd_install() es llamado después de que copy_to_user() tenga éxito.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/huge_memory: no desvenenes a huge_zero_folio Cuando hice pruebas de falla de memoria recientemente, se produjo el siguiente pánico: ¡ERROR del kernel en include/linux/mm.h:1135! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 137 Comm: kswapd1 No está contaminado 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14 RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0 RSP: 0018:ffff 9933c6c57bd0 EFLAGS : 00000246 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: 5c9c0 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492 R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 000000000000000000000 000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00 FS: 0000000000000000 (0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f4da6e9878 CR3: 048000 CR4: 00000000000006f0 Seguimiento de llamadas: do_shrink_slab+0x14f/0x6a0 Shrink_slab+0xca/0x8c0 Shrink_node +0x2d0/0x7d0 balance_pgdat+0x33a/0x720 kswapd+0x1f3/0x410 kthread+0xd5/0x100 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 Módulos vinculados en: mce_inject hwpoison_inject ---[ traza final 0000000000000000 ]--- RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61 fc5c9c8 RDX: 0000000000000000 RSI: 00000000000000027 RDI: ffff88f61fc5c9c0 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 00000000000005492 : 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00 FS: 0000000000000000(0000) GS:ffff88f61fc40000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 0000000000000 6f0 La raíz La causa es que el indicador HWPoison se establecerá para Huge_zero_folio sin aumentar la referencia del folio. Pero luego unpoison_memory() disminuirá el refcnt del folio inesperadamente, ya que aparece como un folio envenenado exitosamente que conduce a VM_BUG_ON_PAGE(page_ref_count(page) == 0) al liberar huge_zero_folio. Omita la eliminación de veneno de huge_zero_folio en unpoison_memory() para solucionar este problema. Aún no estamos preparados para desvenenar a Huge_zero_folio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: reescribe __kernel_map_pages() para arreglar el modo de dormir en un contexto no válido. __kernel_map_pages() es una función de depuración que borra el bit válido en la entrada de la tabla de páginas para páginas designadas para detectar accesos ilegales a la memoria de las páginas liberadas. Esta función establece/borra el bit válido usando __set_memory(). __set_memory() adquiere el semáforo de init_mm y esta operación puede suspenderse. Esto es problemático, porque __kernel_map_pages() se puede llamar en un contexto atómico y, por lo tanto, es ilegal dormir. Un ejemplo de advertencia de que esto causa: ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/rwsem.c:1578 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, nombre: kthreadd preempt_count: 2, esperado: 0 CPU: 0 PID: 2 Comm: kthreadd No contaminado 6.9.0-g1d4c6d784ef6 #37 Nombre de hardware: riscv-virtio,qemu (DT) Seguimiento de llamadas: [] dump_backtrace+0x1c/0x24 [] show_stack+0x2c/0x38 [] dump_stack_lvl+0x5a/0x72 [] dump_stack+0x14/0x1c [] __might_resched+0x104/0x10e [] __might_sleep+0x3e/0x62 [] down_write+0x20/0x72 [] __set_memory+0x82/0x2fa [] __kernel_map_pages+0x5a/0xd4 [] __alloc_pages_bulk+0x3b2/0x43a [] __vmalloc_node_range+0x196/0x6ba [] copy_process+0x72c/0x17ec [] kernel_clone+0x60/0x2fe [] kernel_thread+0x82/0xa0 [] kthreadd+0x14a/0x1be [] _from_fork+0xe/0x1c Reescribe esta función con apply_to_existing_page_range(). Está bien no tener ningún bloqueo, porque __kernel_map_pages() funciona con páginas que se asignan/desasignan y, mientras tanto, nadie más cambia esas páginas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/exynos: hdmi: informa el modo seguro 640x480 como respaldo cuando no se encuentra EDID Cuando falla la lectura de EDID y el controlador informa que no hay modos disponibles, el núcleo DRM agrega un modo artificial de 1024x786 al conector. Desafortunadamente, algunas variantes del Exynos HDMI (como la de los SoC Exynos4) no pueden controlar dicho modo, por lo que informa un modo seguro de 640x480 en lugar de nada en caso de falla en la lectura de EDID. Esto soluciona el siguiente problema observado en la placa Trats2 desde El commit 13d5b040363c ("drm/exynos: no devuelve valores negativos de .get_modes()"): [drm] Exynos DRM: uso del dispositivo 11c00000.fimd para operaciones de mapeo DMA exynos-drm exynos -drm: enlazado 11c00000.fimd (ops fimd_component_ops) exynos-drm exynos-drm: enlazado 12c10000.mixer (ops Mixer_component_ops) exynos-dsi 11c80000.dsi: [drm:samsung_dsim_host_attach] Dispositivo s6e8aa0 adjunto (carriles:4 bpp:24 modo- flags:0x10b) exynos-drm exynos-drm: enlazado 11c80000.dsi (ops exynos_dsi_component_ops) exynos-drm exynos-drm: enlazado 12d00000.hdmi (ops hdmi_component_ops) [drm] Inicializado exynos 1.1.0 20180330 para exynos-drm en menor 1 exynos-hdmi 12d00000.hdmi: [drm:hdmiphy_enable.part.0] *ERROR* PLL no pudo alcanzar el estado estable panel-samsung-s6e8aa0 11c80000.dsi.0: ID: 0xa2, 0x20, 0x8c exynos-mixer 12c10000.mixer: tiempo de espera de espera para VSYNC ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 11 en drivers/gpu/drm/drm_atomic_helper.c :1682 drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8 [CRTC:70:crtc-1] Se agotó el tiempo de espera de vblank Módulos vinculados en: CPU: 1 PID: 11 Comm: kworker/u16:0 No contaminado 6.9.0-rc5-next -20240424 #14913 Nombre de hardware: Samsung Exynos (árbol de dispositivos aplanados) Cola de trabajo: events_unbound deferred_probe_work_func Rastreo de llamadas: unwind_backtrace de show_stack+0x10/0x14 show_stack de dump_stack_lvl+0x68/0x88 dump_stack_lvl de __warn+0x7c/0x1c4 de warn_slowpath_fmt+0x11c/0x1a8 warn_slowpath_fmt de drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8 drm_atomic_helper_wait_for_vblanks.part.0 de drm_atomic_helper_commit_tail_rpm+0x7c/0x8c drm_atomic_helper_commit_tail_rpm de commit_tail+0x9c/0x184 commit_tail de drm_atomic_helper _commit+0x168/0x190 drm_atomic_helper_commit de drm_atomic_commit+0xb4/0xe0 drm_atomic_commit de drm_client_modeset_commit_atomic+0x23c/0x27c drm_client_modeset_commit_atomic de drm_client_modeset_commit_locked+0x60/0x1cc drm_client_modeset_commit_locked de drm_client_modeset_commit+0x24/0x40 drm_client_modeset_commit de __drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc4 restaurar_fbdev_mode_unlocked de drm_fb_helper_set_par+0x2c/0x3c drm_fb_helper_set_par de fbcon_init+0x3d8/0x550 fbcon_init de visual_init+0xc0/0x108 visual_init de do_bind_con_driver+0x1b8/0x3a4 r de do_take_over_console+0x140/0x1ec do_take_over_console de do_fbcon_takeover+0x70/0xd0 do_fbcon_takeover de fbcon_fb_registered+0x19c/0x1ac fbcon_fb_registered de Register_framebuffer+0x190/0x21c Register_framebuffer de __drm_fb_helper_initial _config_and_unlock+0x350/0x574 __drm_fb_helper_initial_config_and_unlock de exynos_drm_fbdev_client_hotplug+0x6c/0xb0 exynos_drm_fbdev_client_hotplug de drm_client_register+0x58/0x94 drm_client_register de exynos_drm_bind +0x160/0x190 exynos_drm_bind de try_to_bring_up_aggregate_device+0x200/0x2d8 try_to_bring_up_aggregate_device de __component_add+0xb0/0x170 __component_add de Mixer_probe+0x74/0xcc Mixer_probe de platform_probe+0x5c/0x b8 platform_probe de Actually_probe+0xe0/0x3d8realmente_probe de __driver_probe_device+0x9c/0x1e4 __driver_probe_device de driver_probe_device+ 0x30/0xc0 driver_probe_device de __device_attach_driver+0xa8/0x120 __device_attach_driver de bus_for_each_drv+0x80/0xcc bus_for_each_drv de __device_attach+0xac/0x1fc __device_attach de bus_probe_device+0x8c/0x90 _dispositivo de diferido_probe_work_func+0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Ajusta el registro de mensajes de firmware en caso de token liberado en __hwrm_send() En caso de que el token se libere debido al token->estado == BNXT_HWRM_DEFERRED, token liberado (establecido en NULL ) se utiliza en mensajes de registro. Se espera que este problema se evite mediante el código de error HWRM_ERR_CODE_PF_UNAVAILABLE. Pero este código de error lo devuelve un firmware reciente. Por lo tanto, es posible que algunos firmware no lo devuelvan. Esto puede provocar una desreferencia del puntero NULL. Ajuste este problema agregando una verificación del puntero del token. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/io-wq: use set_bit() y test_bit() en trabajador->flags Utilice set_bit() y test_bit() en trabajador->flags dentro de io_uring/io-wq para abordar posibles ejecucións de datos. Se puede acceder a la estructura io_worker->flags a través de varias rutas de datos, lo que genera problemas de concurrencia. Cuando KCSAN está habilitado, revela ejecucións de datos que ocurren en las funciones io_worker_handle_work y io_wq_activate_free_worker. ERROR: KCSAN: ejecución de datos en io_worker_handle_work/io_wq_activate_free_worker escribe en 0xffff8885c4246404 de 4 bytes por tarea 49071 en la CPU 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) (io_durante/io -wq.c:?) leer en 0xffff8885c4246404 de 4 bytes por tarea 49024 en la CPU 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io- wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198) Números de línea contra El commit 18daea77cca6 ("Etiqueta de combinación 'para -linus' de git://git.kernel.org/pub/scm/virt/kvm/kvm"). Estas ejecuciones implican escrituras y lecturas en la misma ubicación de memoria mediante diferentes tareas que se ejecutan en diferentes CPU. Para mitigar esto, refactorice el código para usar operaciones atómicas como set_bit(), test_bit() y clear_bit() en lugar de operaciones básicas "y" y "o". Esto garantiza una manipulación segura para subprocesos de los indicadores de los trabajadores. Además, mueva `create_index` para evitar agujeros en la estructura.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ionic: corrige el pánico del kernel en la acción XDP_TX En la ruta XDP_TX, el controlador ionic envía un paquete a la ruta TX con la página rx y la dirección dma correspondiente. Una vez finalizada la transmisión, ionic_tx_clean() libera esa página. Pero el búfer de anillo RX no se restablece a NULL. Por lo tanto, utiliza una página liberada, lo que provoca pánico en el kernel. ERROR: no se puede manejar el error de página para la dirección: ffff8881576c110c PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060 Ups: Ups: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI CPU: 1 PID: 25 Comunicaciones: ksoftirqd/1 No contaminado 6.9. 0+ #11 Nombre del hardware: Nombre del producto del sistema ASUS/PRIME Z690-P D4, BIOS 0603 01/11/2021 RIP: 0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f Código: 00 53 41 55 41 56 41 57 b8 01 0 00 00 48 8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8 RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283 RAX: 0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002 RDX: ffffffffc0051f64 RSI: ffffc90002d33048 RDI: ffff8881576c110e RBP: ffff888104e6fa88 R08: 0000000000000000 R09 : ffffed1027a04a23 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8 R13: ffff8881589f800f R14: ffff8881576c1100 R15: 0001576c1100 FS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0 PKRU: 55555554 Seguimiento de llamadas: ? __morir+0x20/0x70 ? page_fault_oops+0x254/0x790? __pfx_page_fault_oops+0x10/0x10? __pfx_is_prefetch.constprop.0+0x10/0x10 ? search_bpf_extables+0x165/0x260? fixup_exception+0x4a/0x970? exc_page_fault+0xcb/0xe0? asm_exc_page_fault+0x22/0x30? 0xffffffffc0051f64? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f? do_raw_spin_unlock+0x54/0x220 ionic_rx_service+0x11ab/0x3010 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? ionic_tx_clean+0x29b/0xc60 [iónico 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? __pfx_ionic_tx_clean+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? ionic_tx_cq_service+0x25d/0xa00 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_cq_service+0x69/0x150 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] x_napi+0x11a/0x540 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x7e7/0xc30 ? __pfx_net_rx_action+0x10/0x10

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: hns3: soluciona el problema de falla del kernel en un escenario concurrente Cuando el estado del enlace cambia, el controlador nic debe notificar al controlador roce para manejar este evento, pero en este momento, el controlador roce puede desiniciar y luego causar un fallo del kernel. Para solucionar el problema, cuando cambia el estado del enlace, es necesario verificar si el roce se registró y, cuando se desinstala, es necesario esperar a que finalice la actualización del enlace.