Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: corrige la falta de Hugetlb_lock para descarga de resv. Hay un informe reciente sobre UFFDIO_COPY sobre Hugetlb: https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/ 350: lockdep_assert_held(&hugetlb_lock); Debería ser un problema en hugetlb pero se activa en un contexto de error de usuario, donde entra en la ruta poco probable en la que dos subprocesos modifican el mapa resv juntos. Mike tiene una solución en esa ruta para la descarga de resv, pero parece que se pasó por alto el criterio de bloqueo: hugetlb_cgroup_uncharge_folio_rsvd() actualizará el puntero de cgroup, por lo que es necesario llamarlo con el bloqueo retenido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: soluciona el lavado previo al agregar un archivo en modo de escritura directa. En netfs_perform_write(), cuando se especifica el archivo marcado como NETFS_ICTX_WRITETHROUGH o O_*SYNC o RWF_*SYNC, escriba -El almacenamiento en caché se realiza en un archivo almacenado en búfer. Al configurar la escritura directa, eliminamos cualquier escritura conflictiva en la región y esperamos a que se complete la escritura, fallando si hay un error de escritura que devolver. El problema surge si escribimos en la posición EOF o por encima de ella porque nos saltamos el color y, lo que es más importante, la espera. Esto se convierte en un problema si hay un folio parcial al final del archivo que se está escribiendo y queremos escribir en él también. Tanto la escritura que ya se está ejecutando como la escritura que comenzamos quieren borrar la marca de reescritura, pero quienquiera que esté en segundo lugar genera una advertencia similar a: ------------[cortar aquí]---- -------- R=00000012: el folio 11 no está bajo reescritura ADVERTENCIA: CPU: 34 PID: 654 en fs/netfs/write_collect.c:105 ... CPU: 34 PID: 654 Comm: kworker/u386 :27 Contaminado: GS... ... Cola de trabajo: events_unbound netfs_write_collection_worker... RIP: 0010:netfs_writeback_lookup_folio Solucione este problema haciendo que el lavado y la espera sean incondicionales. No hará nada si no hay publicaciones en el caché de páginas y regresará rápidamente si no hay publicaciones en la región especificada. Además, mueva el archivo adjunto de WBC por encima de la llamada de descarga, ya que la descarga conectará un WBC y lo separará nuevamente si no está presente, y dado que necesitamos uno de todos modos, también podríamos compartirlo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dpll: corrige dpll_pin_on_pin_register() para múltiples pines principales En un escenario donde el pin se registra con múltiples pines principales a través de dpll_pin_on_pin_register(..), todos pertenecientes al mismo dispositivo dpll. Una segunda llamada a dpll_pin_on_pin_unregister(..) provocaría un seguimiento de la llamada, ya que intenta utilizar recursos de registro ya liberados (debido a la solución introducida en b446631f355e). En este escenario, el pin se registró dos veces, por lo que aún no se espera que se liberen recursos hasta que se cancele el registro de cada pin/par de pines registrado. Actualmente, se produce el siguiente seguimiento de fallas/llamadas cuando se elimina el controlador Ice en el sistema con la NIC E810T instalada que incluye el dispositivo dpll: ADVERTENCIA: CPU: 51 PID: 9155 en drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30 RIP: 0010:dpll_pin_ops+0x20/0x30 Seguimiento de llamadas:? __warn+0x7f/0x130 ? dpll_pin_ops+0x20/0x30 dpll_msg_add_pin_freq+0x37/0x1d0 dpll_cmd_pin_get_one+0x1c0/0x400 ? __nlmsg_put+0x63/0x80 dpll_pin_event_send+0x93/0x140 dpll_pin_on_pin_unregister+0x3f/0x100 ice_dpll_deinit_pins+0xa1/0x230 [ice] ice_remove+0xf1/0x210 [ice] Se soluciona agregando un puntero principal como cookie al crear un registro. también al buscarlo . Para los pines normales pasan NULL, esto permite crear un registro separado para cada padre con el que está registrado el pin.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige la dependencia de bloqueo de LAG y VF en ice_reset_vf() 9f74a3dfcf83 ("ice: corrige las rutas de restablecimiento de VF cuando la interfaz está en un agregado de conmutación por error"), el controlador ice ha adquirido el LAG mutex en ice_reset_vf(). La confirmación colocó esta adquisición de bloqueo justo antes de la adquisición del bloqueo de configuración VF. Si ice_reset_vf() adquiere el bloqueo de configuración a través del indicador ICE_VF_RESET_LOCK, esto podría bloquearse con ice_vc_cfg_qs_msg() porque siempre adquiere los bloqueos en el orden del bloqueo de configuración VF y luego el mutex LAG. Lockdep informa esta infracción casi inmediatamente al crear y luego eliminar 2 VF: ===================================== ================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.8.0-rc6 #54 Contaminado: GWO --------------- --------------------------------------- kworker/60:3/6771 está intentando adquirir bloqueo: ff40d43e099380a0 (&vf->cfg_lock){+.+.}-{3:3}, en: ice_reset_vf+0x22f/0x4d0 [ice] pero la tarea ya mantiene el bloqueo: ff40d43ea1961210 (&pf->lag_mutex){+.+ .}-{3:3}, en: ice_reset_vf+0xb7/0x4d0 [ice] cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (&pf->lag_mutex){+.+.}-{3:3}: __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 __mutex_lock+0x9b/0xbf0 ice_vc_cfg_qs_msg +0x45/0x690 [ice] ice_vc_process_vf_msg+0x4f5/0x870 [ice] __ice_clean_ctrlq+0x2b5/0x600 [ice] ice_service_task+0x2c9/0x480 [ice] Process_one_work+0x1e9/0x4d0 trabajador_thread+0x1e1/0x3d0 leer+0x104/0x140 ret_from_fork+0x31/ 0x50 ret_from_fork_asm+0x1b/0x30 -> #0 (&vf->cfg_lock){+.+.}-{3:3}: check_prev_add+0xe2/0xc50 validar_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 ex_lock +0x9b/0xbf0 ice_reset_vf+0x22f/0x4d0 [ice] ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] Process_one_work+0x1e9/0x4d0 trabajador_thread+0x1e1/0x3d0 kthread+0x104/0x1 40 ret_from_fork+0x31/0x50 ret_from_fork_asm+ 0x1b/0x30 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock(&pf->lag_mutex); bloquear(&vf->cfg_lock); bloquear(&pf->lag_mutex); bloquear(&vf->cfg_lock); *** DEADLOCK *** 4 bloqueos retenidos por kworker/60:3/6771: #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, en: Process_one_work+0x176/0x4d0 # 1: ff50d06e05197e58 ((work_completion)(&pf->serv_task)){+.+.}-{0:0}, en: Process_one_work+0x176/0x4d0 #2: ff40d43ea1960e50 (&pf->vfs.table_lock){+.+ .}-{3:3}, en: ice_process_vflr_event+0x48/0xd0 [ice] #3: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, en: ice_reset_vf+0xb7/0x4d0 [ ice] seguimiento de pila: CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: GWO 6.8.0-rc6 #54 Nombre de hardware: Cola de trabajo: ice ice_service_task [ice] Seguimiento de llamadas: dump_stack_lvl+0x4a/0x80 check_noncircular +0x12d/0x150 check_prev_add+0xe2/0xc50 ? save_trace+0x59/0x230? add_chain_cache+0x109/0x450 validar_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40? lockdep_hardirqs_on+0x7d/0x100 lock_acquire+0xd4/0x2d0? ice_reset_vf+0x22f/0x4d0 [ice]? lock_is_held_type+0xc7/0x120 __mutex_lock+0x9b/0xbf0 ? ice_reset_vf+0x22f/0x4d0 [ice]? ice_reset_vf+0x22f/0x4d0 [ice]? rcu_is_watching+0x11/0x50? ice_reset_vf+0x22f/0x4d0 [ice] ice_reset_vf+0x22f/0x4d0 [ice] ? Process_one_work+0x176/0x4d0 ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] Process_one_work+0x1e9/0x4d0 trabajador_thread+0x1e1/0x3d0? __pfx_worker_thread+0x10/0x10 kthread+0x104/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Para evitar un punto muerto, debemos adquirir el LAG ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv4: verifique NULL idev en ip_route_use_hint() syzbot pudo activar una deref NULL en fib_validate_source() en un árbol antiguo [1]. Parece que el error existe en los árboles más recientes. Todas las llamadas a __in_dev_get_rcu() deben verificarse para obtener un resultado NULL. [1] Fallo de protección general, probablemente para la dirección no canónica 0xdffffc000000000000: 0000 [#1] SMP Kasan Kasan: Null-Ptr-Deref en el rango [0x000000000000000000-0X000000000000000007] CPU: 2 pid: 3257 Comm: Syz-ECUTOR.3 NO NO tainted 5.10.0-syzkaller #0 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 RIP: 0010:fib_validate_source+0xbf /0x15a0 net/ipv4/fib_frontend.c:425 Código: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 RAX: 0000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 RDX: 0000000000000000 RSI : 0000000004001eac RDI: ffff8880160c64c0 RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 R10: 0000000000000002 R11: 00f4f90c0 R12: dffffc0000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 FS: 00007f938acfe6c0(0000) GS:ffff888058c0 0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 00000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ip_route_use_hint+0x410/0x9b0 net/ipv4/route. c:2231 ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327 ip_list_rcv_finish net/ipv4/ip_input.c:612 [en línea] ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638 /0x470 neto /ipv4/ip_input.c:673 __netif_receive_skb_list_ptype net/core/dev.c:5572 [en línea] __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620 __netif_receive_skb_list net/core/dev.c:5672 [en línea] ive_skb_list_internal+ 0x9f9/0xdc0 net/core/dev.c:5764 netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816 xdp_recv_frames net/bpf/test_run.c:257 [en línea] xdp_test_run_batch net/bpf/test_run.c:335 [ en línea] bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363 bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376 bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c: 3736 __sys_bpf+0x45c/0x710 núcleo /bpf/syscall.c:5115 __do_sys_bpf kernel/bpf/syscall.c:5201 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5199 [en línea] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ax25: soluciona el problema de recuento de netdev. El dev_tracker se agrega a ax25_cb en ax25_bind(). Cuando el dispositivo ax25 se está desconectando, el dev_tracker de ax25_cb debe desasignarse en ax25_kill_by_device() en lugar del dev_tracker de ax25_dev. El registro informado por ref_tracker se muestra a continuación: [80.884935] ref_tracker: referencia ya publicada. [80.885150] ref_tracker: asignado en: [80.885349] ax25_dev_device_up+0x105/0x540 [80.885730] ax25_device_event+0xa4/0x420 [80.885730] notifier_call_chain+0xc9/0x1e0 [80. 885730] __dev_notify_flags+0x138/0x280 [ 80.885730] dev_change_flags+0xd7/0x180 [ 80.885730 ] dev_ifsioc+0x6a9/0xa30 [ 80.885730] dev_ioctl+0x4d8/0xd90 [ 80.885730] sock_do_ioctl+0x1c2/0x2d0 [ 80.885730] sock_ioctl+0x38b/0x4f0 [ 80.885730] __se_sys_ioctl+0xad/0xf0 [ 80.885730] do_syscall_64+0xc4/0x1b0 [ 80.885730] Entry_SYSCALL_64_after_hwframe +0x67/0x6f [ 80.885730] ref_tracker: liberado en: [ 80.885730] ax25_device_event+0x272/0x420 [ 80.885730] notifier_call_chain+0xc9/0x1e0 [ 80.885730] 370 [80.885730] unregister_netdevice_many_notify+0x3b5/0x1180 [80.885730] unregister_netdev+0xcf /0x120 [ 80.885730] sixpack_close+0x11f/0x1b0 [ 80.885730] tty_ldisc_kill+0xcb/0x190 [ 80.885730] tty_ldisc_hangup+0x338/0x3d0 [ 80.885730] x740 [ 80.885730] tty_release+0x46e/0xd80 [ 80.885730] __fput+0x37f/0x770 [80.885730] __x64_sys_close+0x7b/0xb0 [ 80.885730] do_syscall_64+0xc4/0x1b0 [ 80.885730] Entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 80.893739] ------------[ cortar aquí ]--- ---- ----- [80.894030] ADVERTENCIA: CPU: 2 PID: 140 en lib/ref_tracker.c: 255 ref_tracker_free+0x47b/0x6b0 [80.894297] Módulos vinculados en: [80.894929] CPU: 2 pid: 140 Comm: ax25_conn_rel 6 no Tainted 6.9.0-rc4-g8cd26fd90c1a #11 [80.895190] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qem4 [80.895514] RIP:ref_tracker_free +0x47b /0x6b0 [ 80.895808] Código: 83 c5 18 4c 89 eb 48 c1 eb 03 8a 04 13 84 c0 0f 85 df 01 00 00 41 83 7d 00 00 75 4b 4c 89 ff 9 [ 80.896171] 0018:ffff888009edf8c0 EFLAGS: 00000286 [ 80.896339] RAX: 1ffff1100141ac00 RBX: 1ffff1100149463b RCX: dffffc0000000000 [ 80.896502] RDX: 00000000000000001 RSI: 0000000000000246 RDI: ff88800a0d6518 [ 80.896925] RBP: ffff888009edf9b0 R08: ffff88806d3288d3 R09: 1ffff1100da6511a [ 80.897212] R10: dffffc0000000000 R11: 1b R12: ffff88800a4a31d4 [ 80.897859 ] R13: ffff88800a4a31d8 R14: dffffc0000000000 R15: ffff88800a0d6518 [ 80.898279] FS: 00007fd88b7fe700(0000) GS:ffff88806d300000(0000) 000000000000000 [ 80.899436] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 80.900181] CR2: 00007fd88c001d48 CR3 : 000000000993e000 CR4: 00000000000006f0 ... [ 80.935774] ref_tracker: sp%d@000000000bb9df3d tiene 1/1 usuarios en [ 80.935774] ax25_bind+0x424/0x4e0 [ 80.93577 4] __sys_bind+0x1d9/0x270 [ 80.935774] __x64_sys_bind+0x75/0x80 [ 80.935774 ] do_syscall_64+0xc4/0x1b0 [ 80.935774] Entry_SYSCALL_64_after_hwframe+0x67/0x6f Cambie ax25_dev->dev_tracker al dev_tracker de ax25_cb para mitigar el error.

Una vulnerabilidad fue encontrada en PHPGurukul Directory Management System 1.0 y clasificada como problemática. Una función desconocida del archivo /admin/admin-profile.php del componente Searchbar es afectada por esta vulnerabilidad. La manipulación conduce a cross site scripting. El ataque se puede lanzar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. A esta vulnerabilidad se le asignó el identificador VDB-265213.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: Advertencia de corrección durante el rehash Como se explicó anteriormente, el trabajo retrasado del rehash migra filtros de una región a otra. Esto se hace iterando sobre todos los fragmentos (todos los filtros con la misma prioridad) en la región y en cada fragmento iterando sobre todos los filtros. Cuando el trabajo se queda sin créditos, almacena el fragmento y la entrada actuales como marcadores en el contexto por trabajo para saber dónde reanudar la migración la próxima vez que se programe el trabajo. En caso de error, el marcador de fragmento se restablece a NULL, pero sin restablecer los marcadores de entrada a pesar de ser relativos a él. Esto puede provocar que la migración se reanude desde una entrada que no pertenece al fragmento que se está migrando. A su vez, esto eventualmente conducirá a que se repita un fragmento como si fuera una entrada. Debido a cómo se definen las dos estructuras, esto no genera símbolos KASAN, sino advertencias como [1]. Para solucionarlo, cree un asistente que restablezca todos los marcadores y llámelo desde todos los lugares donde actualmente solo restablece el marcador de fragmentos. Por si acaso, llámelo también al iniciar un rehash completamente nuevo. Agregue una advertencia para evitar casos futuros. [1] ADVERTENCIA: CPU: 7 PID: 1076 en drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0 Módulos vinculados en: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted : GW 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Nombre del hardware: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 06/01/2019 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP 0010:mlxsw_af k_encode+0x242/0x2f0 [... ] Seguimiento de llamadas: mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6 c/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: corrige el uso incorrecto de la API de lista. Tanto la función que migra todos los fragmentos dentro de una región como la función que migra todas las entradas dentro de un fragmento llaman a list_first_entry() en el respectivo listas sin verificar que las listas no estén vacías. Este es un uso incorrecto de la API, lo que genera la siguiente advertencia [1]. Para solucionarlo, regrese si las listas están vacías, ya que en este caso no hay nada que migrar. [1] ADVERTENCIA: CPU: 0 PID: 6437 en drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0> Módulos vinculados en: CPU: 0 PID: 6437 Comm: kworker/0:37 No contaminado 6.9.0-rc3-custom-00883-g94a65f079ef6 #39 Nombre del hardware: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 06/01/2019 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP 0010:mlxsw_sp _acl_tcam_vchunk_migrate_all+0x1f1/0x2c0 [... ] Seguimiento de llamadas: mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0 Process_one_work+0x151/0x370 Workers_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x3 0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: honrar el indicador inactivo de la tabla desde la ruta del evento de lanzamiento de netdev. Verifique el indicador inactivo de la tabla; de lo contrario, la ruta del evento de lanzamiento de netdev intenta cancelar el registro de un enlace que ya no está registrado. [524854.857999] ------------[ cortar aquí ]------------ [524854.858010] ADVERTENCIA: CPU: 0 PID: 3386599 en net/netfilter/core.c :501 __nf_unregister_net_hook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 No contaminado 6.9.0-rc3+ #365 [524854.858869] Cola de trabajo: netns cleanup_net [524854 .858886] QEPD: 0010 :__nf_unregister_net_hook+0x21a/0x260 [524854.858903] Código: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 83 y sigs 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 24854.858926] RAX: 00000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 00000000000000 01 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 00000000000000005 [524854.858962] R13: 16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971 ] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Seguimiento de llamadas: [ 524854.859006] [524854.859013] ? __warn+0x9f/0x1a0 [524854.859027] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859044] ? report_bug+0x1b1/0x1e0 [524854.859060] ? handle_bug+0x3c/0x70 [524854.859071] ? exc_invalid_op+0x17/0x40 [524854.859083] ? asm_exc_invalid_op+0x1a/0x20 [524854.859100] ? __nf_unregister_net_hook+0x6a/0x260 [524854.859116] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables] [524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859461] ? packet_notifier+0xb3/0x360 [524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40 [524854.859489] ? dcbnl_netdevice_event+0x35/0x140 [524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859661] notifier_call_chain+0x7d/0x140 [524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i40e: no utilice el indicador WQ_MEM_RECLAIM para la cola de trabajo Problema informado por el cliente durante las pruebas SRIOV, seguimiento de llamadas: cuando se cargan tanto el i40e como el controlador i40iw, se activa una advertencia en check_flush_dependency. Esto parece deberse a que la cola de trabajo del controlador i40e está asignada con el indicador WQ_MEM_RECLAIM, y la del i40iw no. También se encontró un error similar en el ice y se solucionó quitando la bandera. Haz lo mismo con el i40e también. [9 de febrero 09:08] ------------[ cortar aquí ]------------ [ +0.000004] cola de trabajo: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] está vaciando !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000060] ADVERTENCIA: CPU: 0 PID: 937 en kernel/workqueue.c:2966 check_flush_dependency+0x10b/0x120 [ +0.000007] Módulos vinculados en: snd_seq_dummy snd_hrtimer snd_seq snd_timer s nd_seq_device snd soundcore nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod fusible [+0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: cargado No contaminado 6.8.0 -rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Nombre del hardware: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 15/12/2020 [ +0.0000 01] Cola de trabajo: i40e i40e_service_task [i40e ] [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120 [ +0.000003] Código: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 RETRASOS: 00010282 [ + 0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [+0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 00000000000000000(0000) GS:ffff94d47f600000(000) 0) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ + 0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [+0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Seguimiento de llamadas : [ +0.000001] [ +0.000002] ? __advertir+0x80/0x130 [ +0.000003] ? check_flush_dependency+0x10b/0x120 [+0.000002]? report_bug+0x195/0x1a0 [+0.000005]? handle_bug+0x3c/0x70 [+0.000003]? exc_invalid_op+0x14/0x70 [+0.000002]? asm_exc_invalid_op+0x16/0x20 [+0.000006]? check_flush_dependency+0x10b/0x120 [+0.000002]? check_flush_dependency+0x10b/0x120 [ +0.000002] __flush_workqueue+0x126/0x3f0 [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core] [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core] +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core] [ +0.000020] i40iw_close+0x4b/0x90 [irdma] [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e] [ +0.000035] i40e_service_task+0x126/0x190 [i40e] [ +0.000 024] process_one_work+0x174/0x340 [+0.000003] worker_th ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: se corrigió la carga de kernels NOMMU de 64 bits después del inicio de la confirmación de RAM. 3335068f8721 ("riscv: use páginas PUD/P4D/PGD para el mapeo lineal") se agregó lógica para permitir el uso RAM debajo de la dirección de carga del kernel. Sin embargo, esto no funciona para NOMMU, donde PAGE_OFFSET está fijado a la dirección de carga del kernel. Dado que ese rango de memoria corresponde a los PFN por debajo de ARCH_PFN_OFFSET, la inicialización de mm se ejecuta desde el principio de mem_map y corrompe la memoria del kernel adyacente. Solucione este problema restaurando el comportamiento anterior de los núcleos NOMMU.