Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflow<br /> <br /> This reverts commit<br /> 443a98e649b4 ("soundwire: bus: use pm_runtime_resume_and_get()")<br /> <br /> Change calls to pm_runtime_resume_and_get() back to pm_runtime_get_sync().<br /> This fixes a usage count underrun caused by doing a pm_runtime_put() even<br /> though pm_runtime_resume_and_get() returned an error.<br /> <br /> The three affected functions ignore -EACCES error from trying to get<br /> pm_runtime, and carry on, including a put at the end of the function.<br /> But pm_runtime_resume_and_get() does not increment the usage count if it<br /> returns an error. So in the -EACCES case you must not call<br /> pm_runtime_put().<br /> <br /> The documentation for pm_runtime_get_sync() says:<br /> "Consider using pm_runtime_resume_and_get() ... as this is likely to<br /> result in cleaner code."<br /> <br /> In this case I don&amp;#39;t think it results in cleaner code because the<br /> pm_runtime_put() at the end of the function would have to be conditional on<br /> the return value from pm_runtime_resume_and_get() at the top of the<br /> function.<br /> <br /> pm_runtime_get_sync() doesn&amp;#39;t have this problem because it always<br /> increments the count, so always needs a put. The code can just flow through<br /> and do the pm_runtime_put() unconditionally.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix lost destroy smbd connection when MR allocate failed<br /> <br /> If the MR allocate failed, the smb direct connection info is NULL,<br /> then smbd_destroy() will directly return, then the connection info<br /> will be leaked.<br /> <br /> Let&amp;#39;s set the smb direct connection info to the server before call<br /> smbd_destroy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Add missing gfx11 MQD manager callbacks<br /> <br /> mqd_stride function was introduced in commit 2f77b9a242a2<br /> ("drm/amdkfd: Update MQD management on multi XCC setup")<br /> but not assigned for gfx11. Fixes a NULL dereference in debugfs.

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.