Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()<br /> <br /> cpufreq_cpu_get_raw() can return NULL when the target CPU is not present<br /> in the policy-&gt;cpus mask. scpi_cpufreq_get_rate() does not check for<br /> this case, which results in a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()<br /> <br /> cpufreq_cpu_get_raw() can return NULL when the target CPU is not present<br /> in the policy-&gt;cpus mask. scmi_cpufreq_get_rate() does not check for<br /> this case, which results in a NULL pointer dereference.<br /> <br /> Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate()<br /> <br /> cpufreq_cpu_get_raw() can return NULL when the target CPU is not present<br /> in the policy-&gt;cpus mask. apple_soc_cpufreq_get_rate() does not check<br /> for this case, which results in a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads<br /> <br /> Fix niu_try_msix() to not cause a fatal trap on sparc systems.<br /> <br /> Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to<br /> work around a bug in the hardware or firmware.<br /> <br /> For each vector entry in the msix table, niu chips will cause a fatal<br /> trap if any registers in that entry are read before that entries&amp;#39;<br /> ENTRY_DATA register is written to. Testing indicates writes to other<br /> registers are not sufficient to prevent the fatal trap, however the value<br /> does not appear to matter. This only needs to happen once after power up,<br /> so simply rebooting into a kernel lacking this fix will NOT cause the<br /> trap.<br /> <br /> NON-RESUMABLE ERROR: Reporting on cpu 64<br /> NON-RESUMABLE ERROR: TPC [0x00000000005f6900] <br /> NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff<br /> NON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]<br /> NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]<br /> NON-RESUMABLE ERROR: type [precise nonresumable]<br /> NON-RESUMABLE ERROR: attrs [0x02000080] <br /> NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]<br /> NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]<br /> NON-RESUMABLE ERROR: size [0x8]<br /> NON-RESUMABLE ERROR: asi [0x00]<br /> CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63<br /> Workqueue: events work_for_cpu_fn<br /> TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not tainted<br /> TPC: <br /> g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100<br /> g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000<br /> o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620<br /> o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128<br /> RPC: <br /> l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020<br /> l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734<br /> i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d<br /> i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0<br /> I7: <br /> Call Trace:<br /> [] niu_try_msix.constprop.0+0xc0/0x130 [niu]<br /> [] niu_get_invariants+0x183c/0x207c [niu]<br /> [] niu_pci_init_one+0x27c/0x2fc [niu]<br /> [] local_pci_probe+0x28/0x74<br /> [] work_for_cpu_fn+0x8/0x1c<br /> [] process_scheduled_works+0x144/0x210<br /> [] worker_thread+0x13c/0x1c0<br /> [] kthread+0xb8/0xc8<br /> [] ret_from_fork+0x1c/0x2c<br /> [] 0x0<br /> Kernel panic - not syncing: Non-resumable error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmscan: don&amp;#39;t try to reclaim hwpoison folio<br /> <br /> Syzkaller reports a bug as follows:<br /> <br /> Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000<br /> Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users<br /> Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed<br /> page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e<br /> memcg:ffff0000dd6d9000<br /> anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)<br /> raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9<br /> raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000<br /> page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))<br /> ------------[ cut here ]------------<br /> kernel BUG at mm/swap_state.c:184!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> Modules linked in:<br /> CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : add_to_swap+0xbc/0x158<br /> lr : add_to_swap+0xbc/0x158<br /> sp : ffff800087f37340<br /> x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780<br /> x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0<br /> x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4<br /> x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000<br /> x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c<br /> x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b<br /> x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000<br /> x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001<br /> x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000<br /> Call trace:<br /> add_to_swap+0xbc/0x158<br /> shrink_folio_list+0x12ac/0x2648<br /> shrink_inactive_list+0x318/0x948<br /> shrink_lruvec+0x450/0x720<br /> shrink_node_memcgs+0x280/0x4a8<br /> shrink_node+0x128/0x978<br /> balance_pgdat+0x4f0/0xb20<br /> kswapd+0x228/0x438<br /> kthread+0x214/0x230<br /> ret_from_fork+0x10/0x20<br /> <br /> I can reproduce this issue with the following steps:<br /> <br /> 1) When a dirty swapcache page is isolated by reclaim process and the<br /> page isn&amp;#39;t locked, inject memory failure for the page. <br /> me_swapcache_dirty() clears uptodate flag and tries to delete from lru,<br /> but fails. Reclaim process will put the hwpoisoned page back to lru.<br /> <br /> 2) The process that maps the hwpoisoned page exits, the page is deleted<br /> the page will never be freed and will be in the lru forever.<br /> <br /> 3) If we trigger a reclaim again and tries to reclaim the page,<br /> add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is<br /> cleared.<br /> <br /> To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the<br /> hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap<br /> it in shrink_folio_list(), otherwise the folio will fail to be unmaped by<br /> hwpoison_user_mappings() since the folio isn&amp;#39;t in lru list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()<br /> <br /> A race can occur between the MCQ completion path and the abort handler:<br /> once a request completes, __blk_mq_free_request() sets rq-&gt;mq_hctx to<br /> NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in<br /> ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is<br /> dereferenced, the kernel will crash.<br /> <br /> Add a NULL check for the returned hwq pointer. If hwq is NULL, log an<br /> error and return FAILED, preventing a potential NULL-pointer<br /> dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is<br /> removed.<br /> <br /> This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix<br /> ufshcd_abort_one racing issue").<br /> <br /> This is found by our static analysis tool KNighter.

The WP SEO Structured Data Schema plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘Price Range’ parameter in all versions up to, and including, 2.7.11 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts that will execute whenever an administrator accesses the plugin settings page.

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 /> LoongArch: Return NULL from huge_pte_offset() for invalid PMD<br /> <br /> LoongArch&amp;#39;s huge_pte_offset() currently returns a pointer to a PMD slot<br /> even if the underlying entry points to invalid_pte_table (indicating no<br /> mapping). Callers like smaps_hugetlb_range() fetch this invalid entry<br /> value (the address of invalid_pte_table) via this pointer.<br /> <br /> The generic is_swap_pte() check then incorrectly identifies this address<br /> as a swap entry on LoongArch, because it satisfies the "!pte_present()<br /> &amp;&amp; !pte_none()" conditions. This misinterpretation, combined with a<br /> coincidental match by is_migration_entry() on the address bits, leads to<br /> kernel crashes in pfn_swap_entry_to_page().<br /> <br /> Fix this at the architecture level by modifying huge_pte_offset() to<br /> check the PMD entry&amp;#39;s content using pmd_none() before returning. If the<br /> entry is invalid (i.e., it points to invalid_pte_table), return NULL<br /> instead of the pointer to the slot.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen-netfront: handle NULL returned by xdp_convert_buff_to_frame()<br /> <br /> The function xdp_convert_buff_to_frame() may return NULL if it fails<br /> to correctly convert the XDP buffer into an XDP frame due to memory<br /> constraints, internal errors, or invalid data. Failing to check for NULL<br /> may lead to a NULL pointer dereference if the result is used later in<br /> processing, potentially causing crashes, data corruption, or undefined<br /> behavior.<br /> <br /> On XDP redirect failure, the associated page must be released explicitly<br /> if it was previously retained via get_page(). Failing to do so may result<br /> in a memory leak, as the pages reference count is not decremented.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: uprobes: Add missing fence.i after building the XOL buffer<br /> <br /> The XOL (execute out-of-line) buffer is used to single-step the<br /> replaced instruction(s) for uprobes. The RISC-V port was missing a<br /> proper fence.i (i$ flushing) after constructing the XOL buffer, which<br /> can result in incorrect execution of stale/broken instructions.<br /> <br /> This was found running the BPF selftests "test_progs:<br /> uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the<br /> uprobes tests randomly blew up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too<br /> <br /> Similarly to the previous patch, we need to safe guard hfsc_dequeue()<br /> too. But for this one, we don&amp;#39;t have a reliable reproducer.