Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/mlx5e: No clonar los atributos de acción posterior de flujo por segunda vez<br /> <br /> El código ya clona los atributos de acción posterior en mlx5e_clone_flow_attr_for_post_act(). Crear otra copia en mlx5e_tc_post_act_add() es un remanente erróneo de la implementación original. En su lugar, asignar handle-&amp;gt;attribute a post_attr proporcionado por el llamador. Tenga en cuenta que clonar el atributo por segunda vez no solo es un desperdicio, sino que también causa problemas como que la segunda copia no se actualice correctamente en el código de actualización de &amp;#39;neigh&amp;#39;, lo que lleva al siguiente uso después de liberación:<br /> <br /> Feb 21 09:02:00 c-237-177-40-045 kernel: BUG: KASAN: use-after-free in mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_report+0xbb/0x1a0<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_stack+0x1e/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_set_track+0x21/0x30<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: __kasan_kmalloc+0x7a/0x90<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_stack+0x1e/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_set_track+0x21/0x30<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_free_info+0x2a/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ____kasan_slab_free+0x11a/0x1b0<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: page dumped because: kasan: bad access detected<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_core 0000:08:00.0: mlx5_cmd_out_err:803:(pid 8833): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad resource state(0x9), syndrome (0xf2ff71), err(-22)<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_core 0000:08:00.0 enp8s0f0: Failed to add post action rule<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_core 0000:08:00.0: mlx5e_tc_encap_flows_add:190:(pid 8833): Failed to update flow post acts, -22<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: Traza de Llamada:<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: <br /> Feb 21 09:02:00 c-237-177-40-045 kernel: dump_stack_lvl+0x57/0x7d<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: print_report+0x170/0x471<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_report+0xbb/0x1a0<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? __module_address.part.0+0x62/0x200<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? mlx5_cmd_stub_create_flow_table+0xd0/0xd0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? __raw_spin_lock_init+0x3b/0x110<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_cmd_create_fte+0x80/0xb0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: add_rule_fg+0xe80/0x19c0 [mlx5_core]<br /> --<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: Asignado por tarea 13476:<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_stack+0x1e/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_set_track+0x21/0x30<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: __kasan_kmalloc+0x7a/0x90<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_packet_reformat_alloc+0x7b/0x230 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_tc_tun_create_header_ipv4+0x977/0xf10 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_attach_encap+0x15b4/0x1e10 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: post_process_attr+0x305/0xa30 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_tc_add_fdb_flow+0x4c0/0xcf0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_configure_flower+0xcaa/0x4b90 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_rep_setup_tc_cls_flower+0x99/0x1b0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_rep_setup_tc_cb+0x133/0x1e0 [mlx5_core]<br /> --<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: Liberado por tarea 8833:<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_s<br /> ---truncado---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ASoC: códecs: tx-macro: Solución para KASAN: slab-out-of-bounds<br /> <br /> Cuando ejecutamos syzkaller obtenemos el siguiente Out of Bound.<br /> &amp;#39;KASAN: slab-out-of-bounds Read in regcache_flat_read&amp;#39;<br /> <br /> A continuación se muestra el rastreo de pila del problema:<br /> <br /> dump_backtrace+0x0/0x4c8<br /> show_stack+0x34/0x44<br /> dump_stack_lvl+0xd8/0x118<br /> print_address_description+0x30/0x2d8<br /> kasan_report+0x158/0x198<br /> __asan_report_load4_noabort+0x44/0x50<br /> regcache_flat_read+0x10c/0x110<br /> regcache_read+0xf4/0x180<br /> _regmap_read+0xc4/0x278<br /> _regmap_update_bits+0x130/0x290<br /> regmap_update_bits_base+0xc0/0x15c<br /> snd_soc_component_update_bits+0xa8/0x22c<br /> snd_soc_component_write_field+0x68/0xd4<br /> tx_macro_digital_mute+0xec/0x140<br /> <br /> En realidad, no hay necesidad de tener un decimador con 32 bits.<br /> Al limitar la variable con el tipo corto u8, el problema se resuelve.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rcuscale: Mover rcu_scale_writer() schedule_timeout_uninterruptible() a _idle()<br /> <br /> El parámetro del módulo rcuscale.holdoff puede ser usado para retrasar el inicio del kthread rcu_scale_writer(). Sin embargo, el tiempo de espera de tarea colgada se activará cuando el tiempo de espera especificado por rcuscale.holdoff sea mayor que hung_task_timeout_secs:<br /> <br /> runqemu kvm nographic slirp qemuparams="-smp 4 -m 2048M"<br /> bootparams="rcuscale.shutdown=0 rcuscale.holdoff=300"<br /> <br /> [ 247.071753] INFO: tarea rcu_scale_write:59 bloqueada por más de 122 segundos.<br /> [ 247.072529] No contaminado 6.4.0-rc1-00134-gb9ed6de8d4ff #7<br /> [ 247.073400] &amp;#39;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&amp;#39; deshabilita este mensaje.<br /> [ 247.074331] tarea:rcu_scale_write estado:D pila:30144 pid:59 ppid:2 flags:0x00004000<br /> [ 247.075346] Rastreo de Llamada:<br /> [ 247.075660] <br /> [ 247.075965] __schedule+0x635/0x1280<br /> [ 247.076448] ? __pfx___schedule+0x10/0x10<br /> [ 247.076967] ? schedule_timeout+0x2dc/0x4d0<br /> [ 247.077471] ? __pfx_lock_release+0x10/0x10<br /> [ 247.078018] ? enqueue_timer+0xe2/0x220<br /> [ 247.078522] schedule+0x84/0x120<br /> [ 247.078957] schedule_timeout+0x2e1/0x4d0<br /> [ 247.079447] ? __pfx_schedule_timeout+0x10/0x10<br /> [ 247.080032] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.080591] ? __pfx_process_timeout+0x10/0x10<br /> [ 247.081163] ? __pfx_sched_set_fifo_low+0x10/0x10<br /> [ 247.081760] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.082287] rcu_scale_writer+0x6b1/0x7f0<br /> [ 247.082773] ? mark_held_locks+0x29/0xa0<br /> [ 247.083252] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.083865] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.084412] kthread+0x179/0x1c0<br /> [ 247.084759] ? __pfx_kthread+0x10/0x10<br /> [ 247.085098] ret_from_fork+0x2c/0x50<br /> [ 247.085433] <br /> <br /> Este commit por lo tanto reemplaza schedule_timeout_uninterruptible() con schedule_timeout_idle().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bpf: Silenciar una advertencia en btf_type_id_size()<br /> <br /> syzbot informó una advertencia en [1] con el siguiente stacktrace:<br /> WARNING: CPU: 0 PID: 5005 at kernel/bpf/btf.c:1988 btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988<br /> ...<br /> RIP: 0010:btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988<br /> ...<br /> Traza de Llamada:<br /> <br /> map_check_btf kernel/bpf/syscall.c:1024 [inline]<br /> map_create+0x1157/0x1860 kernel/bpf/syscall.c:1198<br /> __sys_bpf+0x127f/0x5420 kernel/bpf/syscall.c:5040<br /> __do_sys_bpf kernel/bpf/syscall.c:5162 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5160 [inline]<br /> __x64_sys_bpf+0x79/0xc0 kernel/bpf/syscall.c:5160<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Con el siguiente btf<br /> [1] DECL_TAG &amp;#39;a&amp;#39; type_id=4 component_idx=-1<br /> [2] PTR &amp;#39;(anon)&amp;#39; type_id=0<br /> [3] TYPE_TAG &amp;#39;a&amp;#39; type_id=2<br /> [4] VAR &amp;#39;a&amp;#39; type_id=3, linkage=static<br /> y cuando bpf_attr.btf_key_type_id = 1 (DECL_TAG),<br /> el siguiente WARN_ON_ONCE en btf_type_id_size() se activa:<br /> if (WARN_ON_ONCE(!btf_type_is_modifier(size_type) &amp;amp;&amp;amp;<br /> !btf_type_is_var(size_type)))<br /> return NULL;<br /> <br /> Tenga en cuenta que &amp;#39;return NULL&amp;#39; es el comportamiento correcto ya que no queremos<br /> que un tipo DECL_TAG sea usado como btf_{key,value}_type_id incluso<br /> para el caso como &amp;#39;DECL_TAG -&amp;gt; STRUCT&amp;#39;. Así que no hay<br /> ningún problema de corrección aquí, solo queremos silenciar la advertencia.<br /> <br /> Para silenciar la advertencia, agregué DECL_TAG como uno de los tipos en<br /> btf_type_nosize() lo que hará que btf_type_id_size() devuelva<br /> NULL antes sin la advertencia.<br /> <br /> [1] https://lore.kernel.org/bpf/000000000000e0df8d05fc75ba86@google.com/

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fs/ntfs3: Añadir comprobación para kmemdup<br /> <br /> Dado que kmemdup puede devolver un puntero NULL,<br /> sería mejor añadir una comprobación para el valor de retorno<br /> para evitar la desreferencia de puntero NULL.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bus: mhi: ep: Solo enviar estado -ENOTCONN si el controlador cliente está disponible<br /> <br /> Para los comandos STOP y RESET, solo enviar el estado de desconexión del canal -ENOTCONN si el controlador cliente está disponible. De lo contrario, resultará en desreferencia de puntero nulo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ksmbd: evitar el acceso fuera de límites en decode_preauth_ctxt()<br /> <br /> Confirmar que la dirección pneg_ctxt-&amp;gt;HashAlgorithms accedida se encuentra dentro del límite de la solicitud SMB; deassemble_neg_contexts() solo verifica que el encabezado smb2_neg_context de ocho bytes + (DataLength controlada por el cliente) estén dentro del límite del paquete, lo cual es insuficiente.<br /> <br /> Verificar sizeof(struct smb2_preauth_neg_context) es excesivo dado que el tipo actualmente asume SMB311_SALT_SIZE bytes de Salt final.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: taprio: Limitar TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME a INT_MAX.<br /> <br /> syzkaller encontró un error de división por cero [0] en div_s64_rem() llamada desde get_cycle_time_elapsed(), donde sched-&amp;gt;cycle_time es el divisor.<br /> <br /> Tenemos pruebas en parse_taprio_schedule() para que cycle_time nunca sea 0, y de hecho cycle_time no es 0 en get_cycle_time_elapsed().<br /> <br /> El problema es que los tipos de divisor son diferentes; cycle_time es s64, pero el argumento de div_s64_rem() es s32.<br /> <br /> syzkaller alimentó esta entrada y 0x100000000 se convierte a s32 para ser 0.<br /> <br /> @TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME={0xc, 0x8, 0x100000000}<br /> <br /> Usamos s64 para cycle_time para convertirlo a ktime_t, así que mantengámoslo y establezcamos el máximo para cycle_time.<br /> <br /> Ya que estamos, prevenimos el desbordamiento en setup_txtime() y añadimos otra prueba en parse_taprio_schedule() para verificar si cycle_time se desborda.<br /> <br /> Además, añadimos un nuevo caso de prueba tdc para este problema.<br /> <br /> [0]:<br /> divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 1 PID: 103 Comm: kworker/1:3 Not tainted 6.5.0-rc1-00330-g60cc1f7d0605 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> RIP: 0010:div_s64_rem include/linux/math64.h:42 [inline]<br /> RIP: 0010:get_cycle_time_elapsed net/sched/sch_taprio.c:223 [inline]<br /> RIP: 0010:find_entry_to_transmit+0x252/0x7e0 net/sched/sch_taprio.c:344<br /> Code: 3c 02 00 0f 85 5e 05 00 00 48 8b 4c 24 08 4d 8b bd 40 01 00 00 48 8b 7c 24 48 48 89 c8 4c 29 f8 48 63 f7 48 99 48 89 74 24 70 &amp;lt;48&amp;gt; f7 fe 48 29 d1 48 8d 04 0f 49 89 cc 48 89 44 24 20 49 8d 85 10<br /> RSP: 0018:ffffc90000acf260 EFLAGS: 00010206<br /> RAX: 177450e0347560cf RBX: 0000000000000000 RCX: 177450e0347560cf<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000100000000<br /> RBP: 0000000000000056 R08: 0000000000000000 R09: ffffed10020a0934<br /> R10: ffff8880105049a7 R11: ffff88806cf3a520 R12: ffff888010504800<br /> R13: ffff88800c00d800 R14: ffff8880105049a0 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff88806cf00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f0edf84f0e8 CR3: 000000000d73c002 CR4: 0000000000770ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> get_packet_txtime net/sched/sch_taprio.c:508 [inline]<br /> taprio_enqueue_one+0x900/0xff0 net/sched/sch_taprio.c:577<br /> taprio_enqueue+0x378/0xae0 net/sched/sch_taprio.c:658<br /> dev_qdisc_enqueue+0x46/0x170 net/core/dev.c:3732<br /> __dev_xmit_skb net/core/dev.c:3821 [inline]<br /> __dev_queue_xmit+0x1b2f/0x3000 net/core/dev.c:4169<br /> dev_queue_xmit include/linux/netdevice.h:3088 [inline]<br /> neigh_resolve_output net/core/neighbour.c:1552 [inline]<br /> neigh_resolve_output+0x4a7/0x780 net/core/neighbour.c:1532<br /> neigh_output include/net/neighbour.h:544 [inline]<br /> ip6_finish_output2+0x924/0x17d0 net/ipv6/ip6_output.c:135<br /> __ip6_finish_output+0x620/0xaa0 net/ipv6/ip6_output.c:196<br /> ip6_finish_output net/ipv6/ip6_output.c:207 [inline]<br /> NF_HOOK_COND include/linux/netfilter.h:292 [inline]<br /> ip6_output+0x206/0x410 net/ipv6/ip6_output.c:228<br /> dst_output include/net/dst.h:458 [inline]<br /> NF_HOOK.constprop.0+0xea/0x260 include/linux/netfilter.h:303<br /> ndisc_send_skb+0x872/0xe80 net/ipv6/ndisc.c:508<br /> ndisc_send_ns+0xb5/0x130 net/ipv6/ndisc.c:666<br /> addrconf_dad_work+0xc14/0x13f0 net/ipv6/addrconf.c:4175<br /> process_one_work+0x92c/0x13a0 kernel/workqueue.c:2597<br /> worker_thread+0x60f/0x1240 kernel/workqueue.c:2748<br /> kthread+0x2fe/0x3f0 kernel/kthread.c:389<br /> ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308<br /> <br /> Modules linked in:

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> platform/x86: think-lmi: Corrige fugas de memoria al analizar cadenas WMI de ThinkStation<br /> <br /> Mi commit anterior introdujo una fuga de memoria donde el elemento asignado de tlmi_setting no fue liberado.<br /> Este commit también lo renombra para evitar confusiones con la variable de nombre similar en la misma función.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: establecer la extensión de página mapeada después de read_folio en relocate_one_page<br /> <br /> Una de las ejecuciones de CI desencadenó el siguiente pánico<br /> <br /> aserción fallida: PagePrivate(page) &amp;amp;&amp;amp; page-&amp;gt;private, en fs/btrfs/subpage.c:229<br /> ------------[ cortar aquí ]------------<br /> BUG del kernel en fs/btrfs/subpage.c:229!<br /> Error interno: Oops - BUG: 00000000f2000800 [#1] SMP<br /> CPU: 0 PID: 923660 Comm: btrfs No contaminado 6.5.0-rc3+ #1<br /> pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> pc : btrfs_subpage_assert+0xbc/0xf0<br /> lr : btrfs_subpage_assert+0xbc/0xf0<br /> sp : ffff800093213720<br /> x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000<br /> x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff<br /> x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880<br /> x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff<br /> x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028<br /> x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000<br /> x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c<br /> x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8<br /> x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f<br /> Traza de llamadas:<br /> btrfs_subpage_assert+0xbc/0xf0<br /> btrfs_subpage_set_dirty+0x38/0xa0<br /> btrfs_page_set_dirty+0x58/0x88<br /> relocate_one_page+0x204/0x5f0<br /> relocate_file_extent_cluster+0x11c/0x180<br /> relocate_data_extent+0xd0/0xf8<br /> relocate_block_group+0x3d0/0x4e8<br /> btrfs_relocate_block_group+0x2d8/0x490<br /> btrfs_relocate_chunk+0x54/0x1a8<br /> btrfs_balance+0x7f4/0x1150<br /> btrfs_ioctl+0x10f0/0x20b8<br /> __arm64_sys_ioctl+0x120/0x11d8<br /> invoke_syscall.constprop.0+0x80/0xd8<br /> do_el0_svc+0x6c/0x158<br /> el0_svc+0x50/0x1b0<br /> el0t_64_sync_handler+0x120/0x130<br /> el0t_64_sync+0x194/0x198<br /> Código: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)<br /> <br /> Este es el mismo problema descrito en 17b17fcd6d44 ("btrfs: establecer la extensión de página mapeada después de read_folio en btrfs_cont_expand"), y la solución es la misma. Originalmente busqué el mismo patrón en otra parte de nuestro código, pero erróneamente omití este código porque vi la lectura anticipada de la caché de páginas antes de set_page_extent_mapped, sin darme cuenta de que esto era solo en el caso de !page, que aún podemos terminar con una página !uptodate y luego hacer el btrfs_read_folio más abajo.<br /> <br /> La solución aquí es la misma que el parche mencionado anteriormente, mover la llamada a set_page_extent_mapped a después del bloque btrfs_read_folio() para asegurarnos de que tenemos la configuración de los elementos de tamaño de bloque de subpágina correctamente antes de usar la página.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/net_failover: fix txq exceeding warning<br /> <br /> The failover txq is inited as 16 queues.<br /> when a packet is transmitted from the failover device firstly,<br /> the failover device will select the queue which is returned from<br /> the primary device if the primary device is UP and running.<br /> If the primary device txq is bigger than the default 16,<br /> it can lead to the following warning:<br /> eth0 selects TX queue 18, but real number of TX queues is 16<br /> <br /> The warning backtrace is:<br /> [ 32.146376] CPU: 18 PID: 9134 Comm: chronyd Tainted: G E 6.2.8-1.el7.centos.x86_64 #1<br /> [ 32.147175] Hardware name: Red Hat KVM, BIOS 1.10.2-3.el7_4.1 04/01/2014<br /> [ 32.147730] Call Trace:<br /> [ 32.147971] <br /> [ 32.148183] dump_stack_lvl+0x48/0x70<br /> [ 32.148514] dump_stack+0x10/0x20<br /> [ 32.148820] netdev_core_pick_tx+0xb1/0xe0<br /> [ 32.149180] __dev_queue_xmit+0x529/0xcf0<br /> [ 32.149533] ? __check_object_size.part.0+0x21c/0x2c0<br /> [ 32.149967] ip_finish_output2+0x278/0x560<br /> [ 32.150327] __ip_finish_output+0x1fe/0x2f0<br /> [ 32.150690] ip_finish_output+0x2a/0xd0<br /> [ 32.151032] ip_output+0x7a/0x110<br /> [ 32.151337] ? __pfx_ip_finish_output+0x10/0x10<br /> [ 32.151733] ip_local_out+0x5e/0x70<br /> [ 32.152054] ip_send_skb+0x19/0x50<br /> [ 32.152366] udp_send_skb.isra.0+0x163/0x3a0<br /> [ 32.152736] udp_sendmsg+0xba8/0xec0<br /> [ 32.153060] ? __folio_memcg_unlock+0x25/0x60<br /> [ 32.153445] ? __pfx_ip_generic_getfrag+0x10/0x10<br /> [ 32.153854] ? sock_has_perm+0x85/0xa0<br /> [ 32.154190] inet_sendmsg+0x6d/0x80<br /> [ 32.154508] ? inet_sendmsg+0x6d/0x80<br /> [ 32.154838] sock_sendmsg+0x62/0x70<br /> [ 32.155152] ____sys_sendmsg+0x134/0x290<br /> [ 32.155499] ___sys_sendmsg+0x81/0xc0<br /> [ 32.155828] ? _get_random_bytes.part.0+0x79/0x1a0<br /> [ 32.156240] ? ip4_datagram_release_cb+0x5f/0x1e0<br /> [ 32.156649] ? get_random_u16+0x69/0xf0<br /> [ 32.156989] ? __fget_light+0xcf/0x110<br /> [ 32.157326] __sys_sendmmsg+0xc4/0x210<br /> [ 32.157657] ? __sys_connect+0xb7/0xe0<br /> [ 32.157995] ? __audit_syscall_entry+0xce/0x140<br /> [ 32.158388] ? syscall_trace_enter.isra.0+0x12c/0x1a0<br /> [ 32.158820] __x64_sys_sendmmsg+0x24/0x30<br /> [ 32.159171] do_syscall_64+0x38/0x90<br /> [ 32.159493] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Fix that by reducing txq number as the non-existent primary-dev does.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/smc: corrige un pánico potencial debido a smc_llc_srv_add_link() sin protección<br /> <br /> Existe una cierta probabilidad de desencadenar el siguiente pánico:<br /> <br /> PID: 5900 TASK: ffff88c1c8af4100 CPU: 1 COMMAND: "kworker/1:48"<br /> #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7<br /> #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a<br /> #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60<br /> #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7<br /> #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715<br /> #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654<br /> #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62<br /> [exception RIP: ib_alloc_mr+19]<br /> RIP: ffffffffc0c9cce3 RSP: ffff9456c1cc7c38 RFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000004<br /> RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffff88c1ea281d00 R8: 000000020a34ffff R9: ffff88c1350bbb20<br /> R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000<br /> R13: 0000000000000010 R14: ffff88c1ab040a50 R15: ffff88c1ea281d00<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc]<br /> #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc]<br /> #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]<br /> <br /> La razón aquí es que cuando el servidor intenta crear un segundo enlace, smc_llc_srv_add_link() no tiene protección y puede añadir un nuevo enlace al grupo de enlaces. Esto rompe el entorno de seguridad protegido por llc_conf_mutex.