Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: hugetlb: avoid soft lockup when mprotect to large memory area<br /> <br /> When calling mprotect() to a large hugetlb memory area in our customer&amp;#39;s<br /> workload (~300GB hugetlb memory), soft lockup was observed:<br /> <br /> watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]<br /> <br /> CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7<br /> Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025<br /> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mte_clear_page_tags+0x14/0x24<br /> lr : mte_sync_tags+0x1c0/0x240<br /> sp : ffff80003150bb80<br /> x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000<br /> x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458<br /> x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000<br /> x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000<br /> x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000<br /> <br /> Call trace:<br />   mte_clear_page_tags+0x14/0x24<br />   set_huge_pte_at+0x25c/0x280<br />   hugetlb_change_protection+0x220/0x430<br />   change_protection+0x5c/0x8c<br />   mprotect_fixup+0x10c/0x294<br />   do_mprotect_pkey.constprop.0+0x2e0/0x3d4<br />   __arm64_sys_mprotect+0x24/0x44<br />   invoke_syscall+0x50/0x160<br />   el0_svc_common+0x48/0x144<br />   do_el0_svc+0x30/0xe0<br />   el0_svc+0x30/0xf0<br />   el0t_64_sync_handler+0xc4/0x148<br />   el0t_64_sync+0x1a4/0x1a8<br /> <br /> Soft lockup is not triggered with THP or base page because there is<br /> cond_resched() called for each PMD size.<br /> <br /> Although the soft lockup was triggered by MTE, it should be not MTE<br /> specific. The other processing which takes long time in the loop may<br /> trigger soft lockup too.<br /> <br /> So add cond_resched() for hugetlb to avoid soft lockup.

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().

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.

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/