Vulnerabilities

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 /> blk-throttle: fix access race during throttle policy activation<br /> <br /> On repeated cold boots we occasionally hit a NULL pointer crash in<br /> blk_should_throtl() when throttling is consulted before the throttle<br /> policy is fully enabled for the queue. Checking only q-&gt;td != NULL is<br /> insufficient during early initialization, so blkg_to_pd() for the<br /> throttle policy can still return NULL and blkg_to_tg() becomes NULL,<br /> which later gets dereferenced.<br /> <br /> Unable to handle kernel NULL pointer dereference<br /> at virtual address 0000000000000156<br /> ...<br /> pc : submit_bio_noacct+0x14c/0x4c8<br /> lr : submit_bio_noacct+0x48/0x4c8<br /> sp : ffff800087f0b690<br /> x29: ffff800087f0b690 x28: 0000000000005f90 x27: ffff00068af393c0<br /> x26: 0000000000080000 x25: 000000000002fbc0 x24: ffff000684ddcc70<br /> x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000<br /> x20: 0000000000080000 x19: ffff000684ddcd08 x18: ffffffffffffffff<br /> x17: 0000000000000000 x16: ffff80008132a550 x15: 0000ffff98020fff<br /> x14: 0000000000000000 x13: 1fffe000d11d7021 x12: ffff000688eb810c<br /> x11: ffff00077ec4bb80 x10: ffff000688dcb720 x9 : ffff80008068ef60<br /> x8 : 00000a6fb8a86e85 x7 : 000000000000111e x6 : 0000000000000002<br /> x5 : 0000000000000246 x4 : 0000000000015cff x3 : 0000000000394500<br /> x2 : ffff000682e35e40 x1 : 0000000000364940 x0 : 000000000000001a<br /> Call trace:<br /> submit_bio_noacct+0x14c/0x4c8<br /> verity_map+0x178/0x2c8<br /> __map_bio+0x228/0x250<br /> dm_submit_bio+0x1c4/0x678<br /> __submit_bio+0x170/0x230<br /> submit_bio_noacct_nocheck+0x16c/0x388<br /> submit_bio_noacct+0x16c/0x4c8<br /> submit_bio+0xb4/0x210<br /> f2fs_submit_read_bio+0x4c/0xf0<br /> f2fs_mpage_readpages+0x3b0/0x5f0<br /> f2fs_readahead+0x90/0xe8<br /> <br /> Tighten blk_throtl_activated() to also require that the throttle policy<br /> bit is set on the queue:<br /> <br /> return q-&gt;td != NULL &amp;&amp;<br /> test_bit(blkcg_policy_throtl.plid, q-&gt;blkcg_pols);<br /> <br /> This prevents blk_should_throtl() from accessing throttle group state<br /> until policy data has been attached to blkgs.

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid migrating empty section<br /> <br /> It reports a bug from device w/ zufs:<br /> <br /> F2FS-fs (dm-64): Inconsistent segment (173822) type [1, 0] in SSA and SIT<br /> F2FS-fs (dm-64): Stopped filesystem due to reason: 4<br /> <br /> Thread A Thread B<br /> - f2fs_expand_inode_data<br /> - f2fs_allocate_pinning_section<br /> - f2fs_gc_range<br /> - do_garbage_collect w/ segno #x<br /> - writepage<br /> - f2fs_allocate_data_block<br /> - new_curseg<br /> - allocate segno #x<br /> <br /> The root cause is: fallocate on pinning file may race w/ block allocation<br /> as above, result in do_garbage_collect() from fallocate() may migrate<br /> segment which is just allocated by a log, the log will update segment type<br /> in its in-memory structure, however GC will get segment type from on-disk<br /> SSA block, once segment type changes by log, we can detect such<br /> inconsistency, then shutdown filesystem.<br /> <br /> In this case, on-disk SSA shows type of segno #173822 is 1 (SUM_TYPE_NODE),<br /> however segno #173822 was just allocated as data type segment, so in-memory<br /> SIT shows type of segno #173822 is 0 (SUM_TYPE_DATA).<br /> <br /> Change as below to fix this issue:<br /> - check whether current section is empty before gc<br /> - add sanity checks on do_garbage_collect() to avoid any race case, result<br /> in migrating segment used by log.<br /> - btw, it fixes misc issue in printed logs: "SSA and SIT" -&gt; "SIT and SSA".

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 /> dm: fix NULL pointer dereference in __dm_suspend()<br /> <br /> There is a race condition between dm device suspend and table load that<br /> can lead to null pointer dereference. The issue occurs when suspend is<br /> invoked before table load completes:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000054<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014<br /> RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50<br /> Call Trace:<br /> <br /> blk_mq_quiesce_queue+0x2c/0x50<br /> dm_stop_queue+0xd/0x20<br /> __dm_suspend+0x130/0x330<br /> dm_suspend+0x11a/0x180<br /> dev_suspend+0x27e/0x560<br /> ctl_ioctl+0x4cf/0x850<br /> dm_ctl_ioctl+0xd/0x20<br /> vfs_ioctl+0x1d/0x50<br /> __se_sys_ioctl+0x9b/0xc0<br /> __x64_sys_ioctl+0x19/0x30<br /> x64_sys_call+0x2c4a/0x4620<br /> do_syscall_64+0x9e/0x1b0<br /> <br /> The issue can be triggered as below:<br /> <br /> T1 T2<br /> dm_suspend table_load<br /> __dm_suspend dm_setup_md_queue<br /> dm_mq_init_request_queue<br /> blk_mq_init_allocated_queue<br /> =&gt; q-&gt;mq_ops = set-&gt;ops; (1)<br /> dm_stop_queue / dm_wait_for_completion<br /> =&gt; q-&gt;tag_set NULL pointer! (2)<br /> =&gt; q-&gt;tag_set = set; (3)<br /> <br /> Fix this by checking if a valid table (map) exists before performing<br /> request-based suspend and waiting for target I/O. When map is NULL,<br /> skip these table-dependent suspend steps.<br /> <br /> Even when map is NULL, no I/O can reach any target because there is<br /> no table loaded; I/O submitted in this state will fail early in the<br /> DM layer. Skipping the table-dependent suspend logic in this case<br /> is safe and avoids NULL pointer dereferences.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: use RCU in ip6_xmit()<br /> <br /> Use RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent<br /> possible UAF.