Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping<br /> <br /> When an invalid value is passed via quirk option, currently<br /> bytcr_rt5640 driver only shows an error message but leaves as is.<br /> This may lead to unepxected results like OOB access.<br /> <br /> This patch corrects the input mapping to the certain default value if<br /> an invalid value is passed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: debugfs: Fix legacy mode page table dump logic<br /> <br /> In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR<br /> maybe uninitialized or zero in that case and may cause oops like:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xf00087d3f000f000: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014<br /> RIP: 0010:pgtable_walk_level+0x98/0x150<br /> RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206<br /> RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e<br /> RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000<br /> RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002<br /> R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000<br /> R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98<br /> FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> pgtable_walk_level+0x88/0x150<br /> domain_translation_struct_show.isra.0+0x2d9/0x300<br /> dev_domain_translation_struct_show+0x20/0x40<br /> seq_read_iter+0x12d/0x490<br /> ...<br /> <br /> Avoid walking the page table if TT is not 00b or 01b.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()<br /> <br /> The drv-&gt;sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which<br /> would lead to a error pointer dereference. Use IS_ERR_OR_NULL() to check<br /> that the pointer is valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller<br /> <br /> When loading the i10nm_edac driver on some Intel Granite Rapids servers,<br /> a call trace may appear as follows:<br /> <br /> UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16<br /> shift exponent -66 is negative<br /> ...<br /> __ubsan_handle_shift_out_of_bounds+0x1e3/0x390<br /> skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]<br /> i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]<br /> skx_register_mci+0x159/0x220 [skx_edac_common]<br /> i10nm_init+0xcb0/0x1ff0 [i10nm_edac]<br /> ...<br /> <br /> This occurs because some BIOS may disable a memory controller if there<br /> aren&amp;#39;t any memory DIMMs populated on this memory controller. The DIMMMTR<br /> register of this disabled memory controller contains the invalid value<br /> ~0, resulting in the call trace above.<br /> <br /> Fix this call trace by skipping DIMM enumeration on a disabled memory<br /> controller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: use RCU in ip6_output()<br /> <br /> Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent<br /> possible UAF.<br /> <br /> We can remove rcu_read_lock()/rcu_read_unlock() pairs<br /> from ip6_finish_output2().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT<br /> <br /> snd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts<br /> via spin_lock_irq(). This also implicitly disables the handling of<br /> softirqs such as TIMER_SOFTIRQ.<br /> On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not<br /> disable them. That means a timer can be invoked during spin_lock_irq()<br /> on the same CPU. Due to synchronisations reasons local_bh_disable() has<br /> a per-CPU lock named softirq_ctrl.lock which synchronizes individual<br /> softirq against each other.<br /> syz-bot managed to trigger a lockdep report where softirq_ctrl.lock is<br /> acquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This<br /> is a possible deadlock.<br /> <br /> The softirq_ctrl.lock can not be made part of spin_lock_irq() as this<br /> would lead to too much synchronisation against individual threads on the<br /> system. To avoid the possible deadlock, softirqs must be manually<br /> disabled before the lock is acquired.<br /> <br /> Disable softirqs before the lock is acquired on PREEMPT_RT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: dont report verifier bug for missing bpf_scc_visit on speculative path<br /> <br /> Syzbot generated a program that triggers a verifier_bug() call in<br /> maybe_exit_scc(). maybe_exit_scc() assumes that, when called for a<br /> state with insn_idx in some SCC, there should be an instance of struct<br /> bpf_scc_visit allocated for that SCC. Turns out the assumption does<br /> not hold for speculative execution paths. See example in the next<br /> patch.<br /> <br /> maybe_scc_exit() is called from update_branch_counts() for states that<br /> reach branch count of zero, meaning that path exploration for a<br /> particular path is finished. Path exploration can finish in one of<br /> three ways:<br /> a. Verification error is found. In this case, update_branch_counts()<br /> is called only for non-speculative paths.<br /> b. Top level BPF_EXIT is reached. Such instructions are never a part of<br /> an SCC, so compute_scc_callchain() in maybe_scc_exit() will return<br /> false, and maybe_scc_exit() will return early.<br /> c. A checkpoint is reached and matched. Checkpoints are created by<br /> is_state_visited(), which calls maybe_enter_scc(), which allocates<br /> bpf_scc_visit instances for checkpoints within SCCs.<br /> <br /> Hence, for non-speculative symbolic execution paths, the assumption<br /> still holds: if maybe_scc_exit() is called for a state within an SCC,<br /> bpf_scc_visit instance must exist.<br /> <br /> This patch removes the verifier_bug() call for speculative paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure<br /> <br /> When devm_add_action_or_reset() fails, it calls the passed cleanup<br /> function. Hence the caller must not repeat that cleanup.<br /> <br /> Replace the "goto err_regulator_free" by the actual freeing, as there<br /> will never be a need again for a second user of this label.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: fix potential deadlock while nr_requests grown<br /> <br /> Allocate and free sched_tags while queue is freezed can deadlock[1],<br /> this is a long term problem, hence allocate memory before freezing<br /> queue and free memory after queue is unfreezed.<br /> <br /> [1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functions<br /> <br /> The function dc_stream_set_cursor_attributes() currently dereferences<br /> the `stream` pointer and nested members `stream-&gt;ctx-&gt;dc-&gt;current_state`<br /> without checking for NULL.<br /> <br /> All callers of these functions, such as in<br /> `dcn30_apply_idle_power_optimizations()` and<br /> `amdgpu_dm_plane_handle_cursor_update()`, already perform NULL checks<br /> before calling these functions.<br /> <br /> Fixes below:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:336 dc_stream_program_cursor_attributes()<br /> error: we previously assumed &amp;#39;stream&amp;#39; could be null (see line 334)<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c<br /> 327 bool dc_stream_program_cursor_attributes(<br /> 328 struct dc_stream_state *stream,<br /> 329 const struct dc_cursor_attributes *attributes)<br /> 330 {<br /> 331 struct dc *dc;<br /> 332 bool reset_idle_optimizations = false;<br /> 333<br /> 334 dc = stream ? stream-&gt;ctx-&gt;dc : NULL;<br /> ^^^^^^<br /> The old code assumed stream could be NULL.<br /> <br /> 335<br /> --&gt; 336 if (dc_stream_set_cursor_attributes(stream, attributes)) {<br /> ^^^^^^<br /> The refactor added an unchecked dereference.<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c<br /> 313 bool dc_stream_set_cursor_attributes(<br /> 314 struct dc_stream_state *stream,<br /> 315 const struct dc_cursor_attributes *attributes)<br /> 316 {<br /> 317 bool result = false;<br /> 318<br /> 319 if (dc_stream_check_cursor_attributes(stream, stream-&gt;ctx-&gt;dc-&gt;current_state, attributes)) {<br /> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here.<br /> This function used to check for if stream as NULL and return false at<br /> the start. Probably we should add that back.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().<br /> <br /> get_netdev_for_sock() is called during setsockopt(),<br /> so not under RCU.<br /> <br /> Using sk_dst_get(sk)-&gt;dev could trigger UAF.<br /> <br /> Let&amp;#39;s use __sk_dst_get() and dst_dev_rcu().<br /> <br /> Note that the only -&gt;ndo_sk_get_lower_dev() user is<br /> bond_sk_get_lower_dev(), which uses RCU.