Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: qdsp6: topology: check widget type before accessing data<br /> <br /> Check widget type before accessing the private data, as this could a<br /> virtual widget which is no associated with a dsp graph, container and<br /> module. Accessing witout check could lead to incorrect memory access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Fix clone_alias() to use the original device&amp;#39;s devid<br /> <br /> Currently clone_alias() assumes first argument (pdev) is always the<br /> original device pointer. This function is called by<br /> pci_for_each_dma_alias() which based on topology decides to send<br /> original or alias device details in first argument.<br /> <br /> This meant that the source devid used to look up and copy the DTE<br /> may be incorrect, leading to wrong or stale DTE entries being<br /> propagated to alias device.<br /> <br /> Fix this by passing the original pdev as the opaque data argument to<br /> both the direct clone_alias() call and pci_for_each_dma_alias(). Inside<br /> clone_alias(), retrieve the original device from data and compute devid<br /> from it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix VM_BIND UNMAP locking<br /> <br /> Wrong argument meant that the objs involved in UNMAP ops were not always<br /> getting locked.<br /> <br /> Since _NO_SHARE objs share a common resv with the VM (which is always<br /> locked) this would only show up with non-_NO_SHARE BOs.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/713898/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: hisilicon/sec2 - prevent req used-after-free for sec<br /> <br /> During packet transmission, if the system is under heavy load,<br /> the hardware might complete processing the packet and free the<br /> request memory (req) before the transmission function finishes.<br /> If the software subsequently accesses this req, a use-after-free<br /> error will occur. The qp_ctx memory exists throughout the packet<br /> sending process, so replace the req with the qp_ctx.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: fix mismatch between power and frequency<br /> <br /> During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops<br /> the MMCX rail to MIN_SVS while the core clock frequency remains at its<br /> original (highest) rate. When runtime resume re-enables the clock, this<br /> may result in a mismatch between the rail voltage and the clock rate.<br /> <br /> For example, in the DPU bind path, the sequence could be:<br /> cpu0: dev_sync_state -&gt; rpmhpd_sync_state<br /> cpu1: dpu_kms_hw_init<br /> timeline 0 ------------------------------------------------&gt; t<br /> <br /> After rpmhpd_sync_state, the voltage performance is no longer guaranteed<br /> to stay at the highest level. During dpu_kms_hw_init, calling<br /> dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to<br /> fall to MIN_SVS while the core clock is still at its maximum frequency.<br /> When the power is re-enabled, only the clock is enabled, leading to a<br /> situation where the MMCX rail is at MIN_SVS but the core clock is at its<br /> highest rate. In this state, the rail cannot sustain the clock rate,<br /> which may cause instability or system crash.<br /> <br /> Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend<br /> to ensure the correct vote is restored when DPU resumes.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/710077/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/riscv: Add IOTINVAL after updating DDT/PDT entries<br /> <br /> Add riscv_iommu_iodir_iotinval() to perform required TLB and context cache<br /> invalidations after updating DDT or PDT entries, as mandated by the RISC-V<br /> IOMMU specification (Section 6.3.1 and 6.3.2).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: tegra124-emc: Fix dll_change check<br /> <br /> The code checking whether the specified memory timing enables DLL<br /> in the EMRS register was reversed. DLL is enabled if bit A0 is low.<br /> Fix the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine<br /> <br /> ksmbd_crypt_message() sets a NULL completion callback on AEAD requests<br /> and does not handle the -EINPROGRESS return code from async hardware<br /> crypto engines like the Qualcomm Crypto Engine (QCE). When QCE returns<br /> -EINPROGRESS, ksmbd treats it as an error and immediately frees the<br /> request while the hardware DMA operation is still in flight. The DMA<br /> completion callback then dereferences freed memory, causing a NULL<br /> pointer crash:<br /> <br /> pc : qce_skcipher_done+0x24/0x174<br /> lr : vchan_complete+0x230/0x27c<br /> ...<br /> el1h_64_irq+0x68/0x6c<br /> ksmbd_free_work_struct+0x20/0x118 [ksmbd]<br /> ksmbd_exit_file_cache+0x694/0xa4c [ksmbd]<br /> <br /> Use the standard crypto_wait_req() pattern with crypto_req_done() as<br /> the completion callback, matching the approach used by the SMB client<br /> in fs/smb/client/smb2ops.c. This properly handles both synchronous<br /> engines (immediate return) and async engines (-EINPROGRESS followed<br /> by callback notification).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi/capsule-loader: fix incorrect sizeof in phys array reallocation<br /> <br /> The krealloc() call for cap_info-&gt;phys in __efi_capsule_setup_info() uses<br /> sizeof(phys_addr_t *) instead of sizeof(phys_addr_t), which might be<br /> causing an undersized allocation.<br /> <br /> The allocation is also inconsistent with the initial array allocation in<br /> efi_capsule_open() that allocates one entry with sizeof(phys_addr_t),<br /> and the efi_capsule_write() function that stores phys_addr_t values (not<br /> pointers) via page_to_phys().<br /> <br /> On 64-bit systems where sizeof(phys_addr_t) == sizeof(phys_addr_t *), this<br /> goes unnoticed. On 32-bit systems with PAE where phys_addr_t is 64-bit but<br /> pointers are 32-bit, this allocates half the required space, which might<br /> lead to a heap buffer overflow when storing physical addresses.<br /> <br /> This is similar to the bug fixed in commit fccfa646ef36 ("efi/capsule-loader:<br /> fix incorrect allocation size") which fixed the same issue at the initial<br /> allocation site.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: prevent NULL pointer dereference during unmount<br /> <br /> When flushing out outstanding glock work during an unmount, gfs2_log_flush()<br /> can be called when sdp-&gt;sd_jdesc has already been deallocated and sdp-&gt;sd_jdesc<br /> is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in<br /> gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it<br /> missed the sdp-&gt;sd_jdesc dereference in gfs2_log_release(). Fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: add some missing log locking<br /> <br /> Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(),<br /> gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp-&gt;sd_log_flush_lock,<br /> but these functions require exclusion against concurrent transactions.<br /> <br /> To fix that, add a non-locking __gfs2_log_flush() function. Then, in<br /> gfs2_logd(), take sdp-&gt;sd_log_flush_lock before calling the above mentioned log<br /> flushing functions and __gfs2_log_flush().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> quota: Fix race of dquot_scan_active() with quota deactivation<br /> <br /> dquot_scan_active() can race with quota deactivation in<br /> quota_release_workfn() like:<br /> <br /> CPU0 (quota_release_workfn) CPU1 (dquot_scan_active)<br /> ============================== ==============================<br /> spin_lock(&amp;dq_list_lock);<br /> list_replace_init(<br /> &amp;releasing_dquots, &amp;rls_head);<br /> /* dquot X on rls_head,<br /> dq_count == 0,<br /> DQ_ACTIVE_B still set */<br /> spin_unlock(&amp;dq_list_lock);<br /> synchronize_srcu(&amp;dquot_srcu);<br /> spin_lock(&amp;dq_list_lock);<br /> list_for_each_entry(dquot,<br /> &amp;inuse_list, dq_inuse) {<br /> /* finds dquot X */<br /> dquot_active(X) -&gt; true<br /> atomic_inc(&amp;X-&gt;dq_count);<br /> }<br /> spin_unlock(&amp;dq_list_lock);<br /> spin_lock(&amp;dq_list_lock);<br /> dquot = list_first_entry(&amp;rls_head);<br /> WARN_ON_ONCE(atomic_read(&amp;dquot-&gt;dq_count));<br /> <br /> The problem is not only a cosmetic one as under memory pressure the<br /> caller of dquot_scan_active() can end up working on freed dquot.<br /> <br /> Fix the problem by making sure the dquot is removed from releasing list<br /> when we acquire a reference to it.