Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: avoid to add interface to list twice when SER<br /> <br /> If SER L2 occurs during the WoWLAN resume flow, the add interface flow<br /> is triggered by ieee80211_reconfig(). However, due to<br /> rtw89_wow_resume() return failure, it will cause the add interface flow<br /> to be executed again, resulting in a double add list and causing a kernel<br /> panic. Therefore, we have added a check to prevent double adding of the<br /> list.<br /> <br /> list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:37!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7<br /> Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021<br /> Workqueue: events_freezable ieee80211_restart_work [mac80211]<br /> RIP: 0010:__list_add_valid_or_report+0x5e/0xb0<br /> Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12<br /> RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246<br /> RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900<br /> RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001<br /> RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0<br /> R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060<br /> R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010<br /> FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0<br /> Call Trace:<br /> <br /> ? __die_body+0x1f/0x70<br /> ? die+0x3d/0x60<br /> ? do_trap+0xa4/0x110<br /> ? __list_add_valid_or_report+0x5e/0xb0<br /> ? do_error_trap+0x6d/0x90<br /> ? __list_add_valid_or_report+0x5e/0xb0<br /> ? handle_invalid_op+0x30/0x40<br /> ? __list_add_valid_or_report+0x5e/0xb0<br /> ? exc_invalid_op+0x3c/0x50<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? __list_add_valid_or_report+0x5e/0xb0<br /> rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f]<br /> drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]<br /> ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]<br /> ? finish_wait+0x3e/0x90<br /> ? synchronize_rcu_expedited+0x174/0x260<br /> ? sync_rcu_exp_done_unlocked+0x50/0x50<br /> ? wake_bit_function+0x40/0x40<br /> ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]<br /> process_scheduled_works+0x1e5/0x480<br /> worker_thread+0xea/0x1e0<br /> kthread+0xdb/0x110<br /> ? move_linked_works+0x90/0x90<br /> ? kthread_associate_blkcg+0xa0/0xa0<br /> ret_from_fork+0x3b/0x50<br /> ? kthread_associate_blkcg+0xa0/0xa0<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev<br /> gsmi: Log Shutdown Reason 0x03<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk_iocost: fix more out of bound shifts<br /> <br /> Recently running UBSAN caught few out of bound shifts in the<br /> ioc_forgive_debts() function:<br /> <br /> UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38<br /> shift exponent 80 is too large for 64-bit type &amp;#39;u64&amp;#39; (aka &amp;#39;unsigned long<br /> long&amp;#39;)<br /> ...<br /> UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30<br /> shift exponent 80 is too large for 64-bit type &amp;#39;u64&amp;#39; (aka &amp;#39;unsigned long<br /> long&amp;#39;)<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xca/0x130<br /> __ubsan_handle_shift_out_of_bounds+0x22c/0x280<br /> ? __lock_acquire+0x6441/0x7c10<br /> ioc_timer_fn+0x6cec/0x7750<br /> ? blk_iocost_init+0x720/0x720<br /> ? call_timer_fn+0x5d/0x470<br /> call_timer_fn+0xfa/0x470<br /> ? blk_iocost_init+0x720/0x720<br /> __run_timer_base+0x519/0x700<br /> ...<br /> <br /> Actual impact of this issue was not identified but I propose to fix the<br /> undefined behaviour.<br /> The proposed fix to prevent those out of bound shifts consist of<br /> precalculating exponent before using it the shift operations by taking<br /> min value from the actual exponent and maximum possible number of bits.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: PAD: fix crash in exit_round_robin()<br /> <br /> The kernel occasionally crashes in cpumask_clear_cpu(), which is called<br /> within exit_round_robin(), because when executing clear_bit(nr, addr) with<br /> nr set to 0xffffffff, the address calculation may cause misalignment within<br /> the memory, leading to access to an invalid memory address.<br /> <br /> ----------<br /> BUG: unable to handle kernel paging request at ffffffffe0740618<br /> ...<br /> CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1<br /> ...<br /> RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]<br /> Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31<br /> RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202<br /> RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246<br /> RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8<br /> R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e<br /> R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e<br /> FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> ? acpi_pad_add+0x120/0x120 [acpi_pad]<br /> kthread+0x10b/0x130<br /> ? set_kthread_struct+0x50/0x50<br /> ret_from_fork+0x1f/0x40<br /> ...<br /> CR2: ffffffffe0740618<br /> <br /> crash&gt; dis -lr ffffffffc0726923<br /> ...<br /> /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114<br /> 0xffffffffc0726918 : mov %r12d,%r12d<br /> /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325<br /> 0xffffffffc072691b : mov -0x3f8d7de0(,%r12,4),%eax<br /> /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80<br /> 0xffffffffc0726923 : lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 <br /> <br /> crash&gt; px tsk_in_cpu[14]<br /> $66 = 0xffffffff<br /> <br /> crash&gt; px 0xffffffffc072692c+0x19cf4<br /> $99 = 0xffffffffc0740620<br /> <br /> crash&gt; sym 0xffffffffc0740620<br /> ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]<br /> <br /> crash&gt; px pad_busy_cpus_bits[0]<br /> $42 = 0xfffc0<br /> ----------<br /> <br /> To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling<br /> cpumask_clear_cpu() in exit_round_robin(), just as it is done in<br /> round_robin_cpu().<br /> <br /> [ rjw: Subject edit, avoid updates to the same value ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/xen-netback: prevent UAF in xenvif_flush_hash()<br /> <br /> During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,<br /> kfree_rcu does not exist inside the rcu read critical section, so if<br /> kfree_rcu is called when the rcu grace period ends during the iteration,<br /> UAF occurs when accessing head-&gt;next after the entry becomes free.<br /> <br /> Therefore, to solve this, you need to change it to list_for_each_entry_safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: Set correct chandef when starting CAC<br /> <br /> When starting CAC in a mode other than AP mode, it return a<br /> "WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]"<br /> caused by the chandef.chan being null at the end of CAC.<br /> <br /> Solution: Ensure the channel definition is set for the different modes<br /> when starting CAC to avoid getting a NULL &amp;#39;chan&amp;#39; at the end of CAC.<br /> <br /> Call Trace:<br /> ? show_regs.part.0+0x14/0x16<br /> ? __warn+0x67/0xc0<br /> ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]<br /> ? report_bug+0xa7/0x130<br /> ? exc_overflow+0x30/0x30<br /> ? handle_bug+0x27/0x50<br /> ? exc_invalid_op+0x18/0x60<br /> ? handle_exception+0xf6/0xf6<br /> ? exc_overflow+0x30/0x30<br /> ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]<br /> ? exc_overflow+0x30/0x30<br /> ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]<br /> ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211]<br /> ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211]<br /> ? process_one_work+0x165/0x280<br /> ? worker_thread+0x120/0x3f0<br /> ? kthread+0xc2/0xf0<br /> ? process_one_work+0x280/0x280<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ? ret_from_fork+0x19/0x24<br /> <br /> [shorten subject, remove OCB, reorder cases to match previous list]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit<br /> <br /> Syzbot points out that skb_trim() has a sanity check on the existing length of<br /> the skb, which can be uninitialised in some error paths. The intent here is<br /> clearly just to reset the length to zero before resubmitting, so switch to<br /> calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()<br /> already contains a call to skb_reset_tail_pointer(), so remove the redundant<br /> call.<br /> <br /> The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there&amp;#39;s a similar<br /> usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we&amp;#39;re at it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start<br /> <br /> In sctp_listen_start() invoked by sctp_inet_listen(), it should set the<br /> sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.<br /> <br /> Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)-&gt;reuse<br /> is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)-&gt;bind_hash will<br /> be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash<br /> is NULL.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617<br /> Call Trace:<br /> <br /> __sys_listen_socket net/socket.c:1883 [inline]<br /> __sys_listen+0x1b7/0x230 net/socket.c:1894<br /> __do_sys_listen net/socket.c:1902 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer<br /> <br /> This commit addresses a potential null pointer dereference issue in the<br /> `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue<br /> could occur when `head_pipe` is null.<br /> <br /> The fix adds a check to ensure `head_pipe` is not null before asserting<br /> it. If `head_pipe` is null, the function returns NULL to prevent a<br /> potential null pointer dereference.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed &amp;#39;head_pipe&amp;#39; could be null (see line 2681)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer<br /> <br /> This commit addresses a potential null pointer dereference issue in the<br /> `dcn201_acquire_free_pipe_for_layer` function. The issue could occur<br /> when `head_pipe` is null.<br /> <br /> The fix adds a check to ensure `head_pipe` is not null before asserting<br /> it. If `head_pipe` is null, the function returns NULL to prevent a<br /> potential null pointer dereference.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed &amp;#39;head_pipe&amp;#39; could be null (see line 1010)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check null pointers before multiple uses<br /> <br /> [WHAT &amp; HOW]<br /> Poniters, such as stream_enc and dc-&gt;bw_vbios, are null checked previously<br /> in the same function, so Coverity warns "implies that stream_enc and<br /> dc-&gt;bw_vbios might be null". They are used multiple times in the<br /> subsequent code and need to be checked.<br /> <br /> This fixes 10 FORWARD_NULL issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check null pointers before used<br /> <br /> [WHAT &amp; HOW]<br /> Poniters, such as dc-&gt;clk_mgr, are null checked previously in the same<br /> function, so Coverity warns "implies that "dc-&gt;clk_mgr" might be null".<br /> As a result, these pointers need to be checked when used again.<br /> <br /> This fixes 10 FORWARD_NULL issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check null pointers before using them<br /> <br /> [WHAT &amp; HOW]<br /> These pointers are null checked previously in the same function,<br /> indicating they might be null as reported by Coverity. As a result,<br /> they need to be checked when used again.<br /> <br /> This fixes 3 FORWARD_NULL issue reported by Coverity.