Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags<br /> <br /> [WHAT &amp; HOW]<br /> "dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it<br /> cannot be a null pointer. Let&amp;#39;s pass a valid pointer to avoid null<br /> dereference.<br /> <br /> This fixes 2 FORWARD_NULL issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb()<br /> <br /> For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is<br /> defined as NR_CPUS instead of the number of possible cpus, this<br /> will cause the following system panic:<br /> <br /> smpboot: Allowing 4 CPUs, 0 hotplug CPUs<br /> ...<br /> setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1<br /> ...<br /> BUG: unable to handle page fault for address: ffffffff9911c8c8<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W<br /> 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6<br /> RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0<br /> RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082<br /> CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0<br /> Call Trace:<br /> <br /> ? __die+0x23/0x80<br /> ? page_fault_oops+0xa4/0x180<br /> ? exc_page_fault+0x152/0x180<br /> ? asm_exc_page_fault+0x26/0x40<br /> ? rcu_tasks_need_gpcb+0x25d/0x2c0<br /> ? __pfx_rcu_tasks_kthread+0x40/0x40<br /> rcu_tasks_one_gp+0x69/0x180<br /> rcu_tasks_kthread+0x94/0xc0<br /> kthread+0xe8/0x140<br /> ? __pfx_kthread+0x40/0x40<br /> ret_from_fork+0x34/0x80<br /> ? __pfx_kthread+0x40/0x40<br /> ret_from_fork_asm+0x1b/0x80<br /> <br /> <br /> Considering that there may be holes in the CPU numbers, use the<br /> maximum possible cpu number, instead of nr_cpu_ids, for configuring<br /> enqueue and dequeue limits.<br /> <br /> [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: avoid reading out of bounds when loading TX power FW elements<br /> <br /> Because the loop-expression will do one more time before getting false from<br /> cond-expression, the original code copied one more entry size beyond valid<br /> region.<br /> <br /> Fix it by moving the entry copy to loop-body.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: efifb: Register sysfs groups through driver core<br /> <br /> The driver core can register and cleanup sysfs groups already.<br /> Make use of that functionality to simplify the error handling and<br /> cleanup.<br /> <br /> Also avoid a UAF race during unregistering where the sysctl attributes<br /> were usable after the info struct was freed.