Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache policy smq: fix missing locks in invalidating cache blocks<br /> <br /> In passthrough mode, the policy invalidate_mapping operation is called<br /> simultaneously from multiple workers, thus it should be protected by a<br /> lock. Otherwise, we might end up with data races on the allocated blocks<br /> counter, or even use-after-free issues with internal data structures<br /> when doing concurrent writes.<br /> <br /> Note that the existing FIXME in smq_invalidate_mapping() doesn&amp;#39;t affect<br /> passthrough mode since migration tasks don&amp;#39;t exist there, but would need<br /> attention if supporting fast device shrinking via suspend/resume without<br /> target reloading.<br /> <br /> Reproduce steps:<br /> <br /> 1. Create a cache device consisting of 1024 cache entries<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 writethrough smq 0"<br /> <br /> 2. Populate the cache, and record the number of cached blocks<br /> <br /> fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \<br /> --size=64m --direct=1<br /> nr_cached=$(dmsetup status cache | awk &amp;#39;{split($7, a, "/"); print a[1]}&amp;#39;)<br /> <br /> 3. Reload the cache into passthrough mode<br /> <br /> dmsetup suspend cache<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 /> dmsetup resume cache<br /> <br /> 4. Write to the passthrough cache. By setting multiple jobs with I/O<br /> size equal to the cache block size, cache blocks are invalidated<br /> concurrently from different workers.<br /> <br /> fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \<br /> --direct=1 --numjobs=2 --randrepeat=0 --size=64m<br /> <br /> 5. Check if demoted matches cached block count. These numbers should<br /> match but may differ due to the data race.<br /> <br /> nr_demoted=$(dmsetup status cache | awk &amp;#39;{print $12}&amp;#39;)<br /> echo "$nr_cached, $nr_demoted"

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix write hang in passthrough mode<br /> <br /> The invalidate_remove() function has incomplete logic for handling write<br /> hit bios after cache invalidation. It sets up the remapping for the<br /> overwrite_bio but then drops it immediately without submission, causing<br /> write operations to hang.<br /> <br /> Fix by adding a new invalidate_committed() continuation that submits<br /> the remapped writes to the cache origin after metadata commit completes,<br /> while using the overwrite_endio hook to ensure proper completion<br /> sequencing. This maintains existing coherency. Also improve error<br /> handling in invalidate_complete() to preserve the original error status<br /> instead of using bio_io_error() unconditionally.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix null-deref with concurrent writes in passthrough mode<br /> <br /> In passthrough mode, when dm-cache starts to invalidate a cache<br /> entry and bio prison cell lock fails due to concurrent write to<br /> the same cached block, mg-&gt;cell remains NULL. The error path in<br /> invalidate_complete() attempts to unlock and free the cell<br /> unconditionally, causing a NULL pointer dereference:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPT<br /> RIP: 0010:dm_cell_unlock_v2+0x3f/0x210<br /> <br /> Call Trace:<br /> invalidate_complete+0xef/0x430<br /> map_bio+0x130f/0x1a10<br /> cache_map+0x320/0x6b0<br /> __map_bio+0x458/0x510<br /> dm_submit_bio+0x40e/0x16d0<br /> __submit_bio+0x419/0x870<br /> <br /> <br /> Reproduce steps:<br /> <br /> 1. Create a cache device<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 writethrough smq 0"<br /> <br /> 2. Promote the first data block into cache<br /> <br /> fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \<br /> --direct=1 --size=64k<br /> <br /> 3. Reload the cache into passthrough mode<br /> <br /> dmsetup suspend cache<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 /> dmsetup resume cache<br /> <br /> 4. Write to the first cached block concurrently<br /> <br /> fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \<br /> --randrepeat=0 --direct=1 --numjobs=2 --size 64k<br /> <br /> Fix by checking if mg-&gt;cell is valid before attempting to unlock it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: sti: use managed regmap_field allocations<br /> <br /> The regmap_field objects allocated at player init are never freed and<br /> may leak resources if the driver is removed.<br /> <br /> Switch to devm_regmap_field_alloc() to automatically limit the lifetime<br /> of the allocations the lifetime of the device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sun4i: backend: fix error pointer dereference<br /> <br /> The function drm_atomic_get_plane_state() can return an error pointer<br /> and is not checked for it. Add error pointer check.<br /> <br /> Detected by Smatch:<br /> drivers/gpu/drm/sun4i/sun4i_backend.c:496 sun4i_backend_atomic_check() error:<br /> &amp;#39;plane_state&amp;#39; dereferencing possible ERR_PTR()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-ep-msi: Fix error unwind and prevent double alloc<br /> <br /> pci_epf_alloc_doorbell() stores the allocated doorbell message array in<br /> epf-&gt;db_msg/epf-&gt;num_db before requesting MSI vectors. If MSI allocation<br /> fails, the array is freed but the EPF state may still point to freed<br /> memory.<br /> <br /> Clear epf-&gt;db_msg and epf-&gt;num_db on the MSI allocation failure path so<br /> that later cleanup cannot double-free the array and callers can retry<br /> allocation.<br /> <br /> Also return -EBUSY when doorbells have already been allocated to prevent<br /> leaking or overwriting an existing allocation.

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.