Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/komeda: fix integer overflow in AFBC framebuffer size check<br /> <br /> The AFBC framebuffer size validation calculates the minimum required<br /> buffer size by adding the AFBC payload size to the framebuffer offset.<br /> This addition is performed without checking for integer overflow.<br /> <br /> If the addition oveflows, the size check may incorrectly succed and<br /> allow userspace to provide an undersized drm_gem_object, potentially<br /> leading to out-of-bounds memory access.<br /> <br /> Add usage of check_add_overflow() to safely compute the minimum<br /> required size and reject the framebuffer if an overflow is detected.<br /> This makes the AFBC size validation more robust against malformed.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomic_enable()<br /> <br /> In case if we get errors in cdns_mhdp_link_up() or cdns_mhdp_reg_read()<br /> in atomic_enable, we will go to cdns_mhdp_modeset_retry_fn() and will hit<br /> NULL pointer while trying to access the mutex. We need the connector to<br /> be set before that. Unlike in legacy cases with flag<br /> !DRM_BRIDGE_ATTACH_NO_CONNECTOR, we do not have connector initialised<br /> in bridge_attach(), so add the mhdp-&gt;connector_ptr in device structure<br /> to handle both cases with DRM_BRIDGE_ATTACH_NO_CONNECTOR and<br /> !DRM_BRIDGE_ATTACH_NO_CONNECTOR, set it in atomic_enable() earlier to<br /> avoid possible NULL pointer dereference in recovery paths like<br /> modeset_retry_fn() with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache metadata: fix memory leak on metadata abort retry<br /> <br /> When failing to acquire the root_lock in dm_cache_metadata_abort because<br /> the block_manager is read-only, the temporary block_manager created<br /> outside the root_lock is not properly released, causing a memory leak.<br /> <br /> Reproduce steps:<br /> <br /> This can be reproduced by reloading a new table while the metadata<br /> is read-only. While the second call to dm_cache_metadata_abort is<br /> caused by lack of support for table preload in dm-cache, mentioned<br /> in commit 9b1cc9f251af ("dm cache: share cache-metadata object across<br /> inactive and active DM tables"), it exposes the memory leak in<br /> dm_cache_metadata_abort when the function is called multiple times.<br /> Specifically, dm-cache fails to sync the new cache object&amp;#39;s mode during<br /> preresume, creating the reproducer condition.<br /> <br /> This issue could also occur through concurrent metadata_operation_failed<br /> calls due to races in cache mode updates, but the table preload scenario<br /> below provides a reliable reproducer.<br /> <br /> 1. Create a cache device with some faulty trailing metadata blocks<br /> <br /> dmsetup create cmeta

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix dirty mapping checking in passthrough mode switching<br /> <br /> As mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata<br /> object across inactive and active DM tables"), dm-cache assumed table<br /> reload occurs after suspension, while LVM&amp;#39;s table preload breaks this<br /> assumption. The dirty mapping check for passthrough mode was designed<br /> around this assumption and is performed during table creation, causing<br /> the check to fail with preload while metadata updates are ongoing. This<br /> risks loading dirty mappings into passthrough mode, resulting in data<br /> loss.<br /> <br /> Reproduce steps:<br /> <br /> 1. Create a writeback cache with zero migration_threshold to produce<br /> dirty mappings<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 262144 linear /dev/sdc 262144"<br /> dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct<br /> dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writeback smq \<br /> 2 migration_threshold 0"<br /> <br /> 2. Preload a table in passthrough mode<br /> <br /> dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0"<br /> <br /> 3. Write to the first cache block to make it dirty<br /> <br /> fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \<br /> --direct=1 --size=64k<br /> <br /> 4. Resume the inactive table. Now it&amp;#39;s possible to load the dirty block<br /> into passthrough mode.<br /> <br /> dmsetup resume cache<br /> <br /> Fix by moving the checks to the preresume phase to support table<br /> preloading. Also remove the unused function dm_cache_metadata_all_clean.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm log: fix out-of-bounds write due to region_count overflow<br /> <br /> The local variable region_count in create_log_context() is declared as<br /> unsigned int (32-bit), but dm_sector_div_up() returns sector_t (64-bit).<br /> When a device-mapper target has a sufficiently large ti-&gt;len with a small<br /> region_size, the division result can exceed UINT_MAX. The truncated<br /> value is then used to calculate bitset_size, causing clean_bits,<br /> sync_bits, and recovering_bits to be allocated far smaller than needed<br /> for the actual number of regions.<br /> <br /> Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) use<br /> region indices derived from the full untruncated region space, causing<br /> out-of-bounds writes to kernel heap memory allocated by vmalloc.<br /> <br /> This can be reproduced by creating a mirror target whose region_count<br /> overflows 32 bits:<br /> <br /> dmsetup create bigzero --table &amp;#39;0 8589934594 zero&amp;#39;<br /> dmsetup create mymirror --table &amp;#39;0 8589934594 mirror \<br /> core 2 2 nosync 2 /dev/mapper/bigzero 0 \<br /> /dev/mapper/bigzero 0&amp;#39;<br /> <br /> The status output confirms the truncation (sync_count=1 instead of<br /> 4294967297, because 0x100000001 was truncated to 1):<br /> <br /> $ dmsetup status mymirror<br /> 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ...<br /> <br /> This leads to a kernel crash in core_in_sync:<br /> <br /> BUG: scheduling while atomic: (udev-worker)/9150/0x00000000<br /> RIP: 0010:core_in_sync+0x14/0x30 [dm_log]<br /> CR2: 0000000000000008<br /> Fixing recursive fault but reboot is needed!<br /> <br /> Fix by widening the local region_count to sector_t and adding an<br /> explicit overflow check before the value is assigned to lc-&gt;region_count.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on<br /> <br /> When PERST# is deasserted twice (assert -&gt; deassert -&gt; assert -&gt; deassert),<br /> a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc<br /> (PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify()<br /> and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers<br /> on the controller core.<br /> <br /> The call chain that causes the timeout:<br /> <br /> pex_ep_event_pex_rst_deassert()<br /> pci_epc_deinit_notify()<br /> pci_epf_test_epc_deinit()<br /> pci_epf_test_clear_bar()<br /> pci_epc_clear_bar()<br /> dw_pcie_ep_clear_bar()<br /> __dw_pcie_ep_reset_bar()<br /> dw_pcie_dbi_ro_wr_en() core_rst) core_rst). Accessing them before this point<br /> results in a CBB timeout because the hardware is not yet operational.<br /> <br /> Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to<br /> after reset_control_deassert(pcie-&gt;core_rst), ensuring the controller is<br /> fully powered on before any DBI register accesses occur.

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