Vulnerabilities

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.

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 /> cpufreq: sun50i: prevent out-of-bounds access<br /> <br /> A KASAN enabled kernel reports an out-of-bounds access when handling the<br /> nvmem cell in the sun50i cpufreq driver:<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in sun50i_cpufreq_nvmem_probe+0x180/0x3d4<br /> Read of size 4 at addr ffff000006bf31e0 by task kworker/u16:1/38<br /> <br /> This is because the DT specifies the nvmem cell as covering only two<br /> bytes, but we use a u32 pointer to read the value. DTs for other SoCs<br /> indeed specify 4 bytes, so we cannot just shorten the variable to a u16.<br /> <br /> Fortunately nvmem_cell_read() allows to return the length of the nvmem<br /> cell, in bytes, so we can use that information to only access the valid<br /> portion of the data.<br /> To cover multiple cell sizes, use memcpy() to copy the information into a<br /> zeroed u32 buffer, then also make sure we always read the data in little<br /> endian fashion, as this is how the data is stored in the SID efuses.

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.

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.

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 /> irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()<br /> <br /> With ACPI in place, gicv2m_get_fwnode() is registered with the pci<br /> subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime<br /> during a PCI host bridge probe. But, the call back is wrongly marked as<br /> __init, causing it to be freed, while being registered with the PCI<br /> subsystem and could trigger:<br /> <br /> Unable to handle kernel paging request at virtual address ffff8000816c0400<br /> gicv2m_get_fwnode+0x0/0x58 (P)<br /> pci_set_bus_msi_domain+0x74/0x88<br /> pci_register_host_bridge+0x194/0x548<br /> <br /> This is easily reproducible on a Juno board with ACPI boot.<br /> <br /> Retain the function for later use.

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 /> sched/eevdf: Fix se-&gt;slice being set to U64_MAX and resulting crash<br /> <br /> There is a code path in dequeue_entities() that can set the slice of a<br /> sched_entity to U64_MAX, which sometimes results in a crash.<br /> <br /> The offending case is when dequeue_entities() is called to dequeue a<br /> delayed group entity, and then the entity&amp;#39;s parent&amp;#39;s dequeue is delayed.<br /> In that case:<br /> <br /> 1. In the if (entity_is_task(se)) else block at the beginning of<br /> dequeue_entities(), slice is set to<br /> cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then<br /> it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX.<br /> 2. The first for_each_sched_entity() loop dequeues the entity.<br /> 3. If the entity was its parent&amp;#39;s only child, then the next iteration<br /> tries to dequeue the parent.<br /> 4. If the parent&amp;#39;s dequeue needs to be delayed, then it breaks from the<br /> first for_each_sched_entity() loop _without updating slice_.<br /> 5. The second for_each_sched_entity() loop sets the parent&amp;#39;s -&gt;slice to<br /> the saved slice, which is still U64_MAX.<br /> <br /> This throws off subsequent calculations with potentially catastrophic<br /> results. A manifestation we saw in production was:<br /> <br /> 6. In update_entity_lag(), se-&gt;slice is used to calculate limit, which<br /> ends up as a huge negative number.<br /> 7. limit is used in se-&gt;vlag = clamp(vlag, -limit, limit). Because limit<br /> is negative, vlag &gt; limit, so se-&gt;vlag is set to the same huge<br /> negative number.<br /> 8. In place_entity(), se-&gt;vlag is scaled, which overflows and results in<br /> another huge (positive or negative) number.<br /> 9. The adjusted lag is subtracted from se-&gt;vruntime, which increases or<br /> decreases se-&gt;vruntime by a huge number.<br /> 10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which<br /> incorrectly returns false because the vruntime is so far from the<br /> other vruntimes on the queue, causing the<br /> (vruntime - cfs_rq-&gt;min_vruntime) * load calulation to overflow.<br /> 11. Nothing appears to be eligible, so pick_eevdf() returns NULL.<br /> 12. pick_next_entity() tries to dereference the return value of<br /> pick_eevdf() and crashes.<br /> <br /> Dumping the cfs_rq states from the core dumps with drgn showed tell-tale<br /> huge vruntime ranges and bogus vlag values, and I also traced se-&gt;slice<br /> being set to U64_MAX on live systems (which was usually "benign" since<br /> the rest of the runqueue needed to be in a particular state to crash).<br /> <br /> Fix it in dequeue_entities() by always setting slice from the first<br /> non-empty cfs_rq.