Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Don&amp;#39;t clone flow post action attributes second time<br /> <br /> The code already clones post action attributes in<br /> mlx5e_clone_flow_attr_for_post_act(). Creating another copy in<br /> mlx5e_tc_post_act_add() is a erroneous leftover from original<br /> implementation. Instead, assign handle-&gt;attribute to post_attr provided by<br /> the caller. Note that cloning the attribute second time is not just<br /> wasteful but also causes issues like second copy not being properly updated<br /> in neigh update code which leads to following use-after-free:<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: Call Trace:<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: Allocated by task 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: Freed by task 8833:<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_s<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: tx-macro: Fix for KASAN: slab-out-of-bounds<br /> <br /> When we run syzkaller we get below Out of Bound.<br /> "KASAN: slab-out-of-bounds Read in regcache_flat_read"<br /> <br /> Below is the backtrace of the issue:<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 /> Actually There is no need to have decimator with 32 bits.<br /> By limiting the variable with short type u8 issue is resolved.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcuscale: Move rcu_scale_writer() schedule_timeout_uninterruptible() to _idle()<br /> <br /> The rcuscale.holdoff module parameter can be used to delay the start<br /> of rcu_scale_writer() kthread. However, the hung-task timeout will<br /> trigger when the timeout specified by rcuscale.holdoff is greater than<br /> 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: task rcu_scale_write:59 blocked for more than 122 seconds.<br /> [ 247.072529] Not tainted 6.4.0-rc1-00134-gb9ed6de8d4ff #7<br /> [ 247.073400] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 247.074331] task:rcu_scale_write state:D stack:30144 pid:59 ppid:2 flags:0x00004000<br /> [ 247.075346] Call Trace:<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 /> This commit therefore replaces schedule_timeout_uninterruptible() with<br /> schedule_timeout_idle().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Silence a warning in btf_type_id_size()<br /> <br /> syzbot reported a warning in [1] with the following 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 /> Call Trace:<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 /> With the following 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 /> and when the bpf_attr.btf_key_type_id = 1 (DECL_TAG),<br /> the following WARN_ON_ONCE in btf_type_id_size() is triggered:<br /> if (WARN_ON_ONCE(!btf_type_is_modifier(size_type) &amp;&amp;<br /> !btf_type_is_var(size_type)))<br /> return NULL;<br /> <br /> Note that &amp;#39;return NULL&amp;#39; is the correct behavior as we don&amp;#39;t want<br /> a DECL_TAG type to be used as a btf_{key,value}_type_id even<br /> for the case like &amp;#39;DECL_TAG -&gt; STRUCT&amp;#39;. So there<br /> is no correctness issue here, we just want to silence warning.<br /> <br /> To silence the warning, I added DECL_TAG as one of kinds in<br /> btf_type_nosize() which will cause btf_type_id_size() returning<br /> NULL earlier without the warning.<br /> <br /> [1] https://lore.kernel.org/bpf/000000000000e0df8d05fc75ba86@google.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Add check for kmemdup<br /> <br /> Since the kmemdup may return NULL pointer,<br /> it should be better to add check for the return value<br /> in order to avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: ep: Only send -ENOTCONN status if client driver is available<br /> <br /> For the STOP and RESET commands, only send the channel disconnect status<br /> -ENOTCONN if client driver is available. Otherwise, it will result in<br /> null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: avoid out of bounds access in decode_preauth_ctxt()<br /> <br /> Confirm that the accessed pneg_ctxt-&gt;HashAlgorithms address sits within<br /> the SMB request boundary; deassemble_neg_contexts() only checks that the<br /> eight byte smb2_neg_context header + (client controlled) DataLength are<br /> within the packet boundary, which is insufficient.<br /> <br /> Checking for sizeof(struct smb2_preauth_neg_context) is overkill given<br /> that the type currently assumes SMB311_SALT_SIZE bytes of trailing Salt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: taprio: Limit TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME to INT_MAX.<br /> <br /> syzkaller found zero division error [0] in div_s64_rem() called from<br /> get_cycle_time_elapsed(), where sched-&gt;cycle_time is the divisor.<br /> <br /> We have tests in parse_taprio_schedule() so that cycle_time will never<br /> be 0, and actually cycle_time is not 0 in get_cycle_time_elapsed().<br /> <br /> The problem is that the types of divisor are different; cycle_time is<br /> s64, but the argument of div_s64_rem() is s32.<br /> <br /> syzkaller fed this input and 0x100000000 is cast to s32 to be 0.<br /> <br /> @TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME={0xc, 0x8, 0x100000000}<br /> <br /> We use s64 for cycle_time to cast it to ktime_t, so let&amp;#39;s keep it and<br /> set max for cycle_time.<br /> <br /> While at it, we prevent overflow in setup_txtime() and add another<br /> test in parse_taprio_schedule() to check if cycle_time overflows.<br /> <br /> Also, we add a new tdc test case for this issue.<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 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:

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: think-lmi: Fix memory leaks when parsing ThinkStation WMI strings<br /> <br /> My previous commit introduced a memory leak where the item allocated<br /> from tlmi_setting was not freed.<br /> This commit also renames it to avoid confusion with the similarly name<br /> variable in the same function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: set page extent mapped after read_folio in relocate_one_page<br /> <br /> One of the CI runs triggered the following panic<br /> <br /> assertion failed: PagePrivate(page) &amp;&amp; page-&gt;private, in fs/btrfs/subpage.c:229<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/subpage.c:229!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> CPU: 0 PID: 923660 Comm: btrfs Not tainted 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 /> Call trace:<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 /> Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)<br /> <br /> This is the same problem outlined in 17b17fcd6d44 ("btrfs:<br /> set_page_extent_mapped after read_folio in btrfs_cont_expand") , and the<br /> fix is the same. I originally looked for the same pattern elsewhere in<br /> our code, but mistakenly skipped over this code because I saw the page<br /> cache readahead before we set_page_extent_mapped, not realizing that<br /> this was only in the !page case, that we can still end up with a<br /> !uptodate page and then do the btrfs_read_folio further down.<br /> <br /> The fix here is the same as the above mentioned patch, move the<br /> set_page_extent_mapped call to after the btrfs_read_folio() block to<br /> make sure that we have the subpage blocksize stuff setup properly before<br /> using the page.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()<br /> <br /> There is a certain chance to trigger the following panic:<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 /> The reason here is that when the server tries to create a second link,<br /> smc_llc_srv_add_link() has no protection and may add a new link to<br /> link group. This breaks the security environment protected by<br /> llc_conf_mutex.