Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a potential use-after-free of BTF object<br /> <br /> Refcounting in the check_pseudo_btf_id() function is incorrect:<br /> the __check_pseudo_btf_id() function might get called with a zero<br /> refcounted btf. Fix this, and patch related code accordingly.<br /> <br /> v3: rephrase a comment (AI)<br /> v2: fix a refcount leak introduced in v1 (AI)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: starfive - Fix memory leak in starfive_aes_aead_do_one_req()<br /> <br /> The starfive_aes_aead_do_one_req() function allocates rctx-&gt;adata with<br /> kzalloc() but fails to free it if sg_copy_to_buffer() or<br /> starfive_aes_hw_init() fails, which lead to memory leaks.<br /> <br /> Since rctx-&gt;adata is unconditionally freed after the write_adata<br /> operations, ensure consistent cleanup by freeing the allocation in these<br /> earlier error paths as well.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: core - use RCU and work_struct to fix race condition<br /> <br /> Currently, hwrng_fill is not cleared until the hwrng_fillfn() thread<br /> exits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutex<br /> lock, a concurrent hwrng_unregister() may call kthread_stop() again on<br /> the same task.<br /> <br /> Additionally, if hwrng_unregister() is called immediately after<br /> hwrng_register(), the stopped thread may have never been executed. Thus,<br /> hwrng_fill remains dirty even after hwrng_unregister() returns. In this<br /> case, subsequent calls to hwrng_register() will fail to start new<br /> threads, and hwrng_unregister() will call kthread_stop() on the same<br /> freed task. In both cases, a use-after-free occurs:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0<br /> Call Trace:<br /> kthread_stop+0x181/0x360<br /> hwrng_unregister+0x288/0x380<br /> virtrng_remove+0xe3/0x200<br /> <br /> This patch fixes the race by protecting the global hwrng_fill pointer<br /> inside the rng_mutex lock, so that hwrng_fillfn() thread is stopped only<br /> once, and calls to kthread_run() and kthread_stop() are serialized<br /> with the lock held.<br /> <br /> To avoid deadlock in hwrng_fillfn() while being stopped with the lock<br /> held, we convert current_rng to RCU, so that get_current_rng() can read<br /> current_rng without holding the lock. To remove the lock from put_rng(),<br /> we also delay the actual cleanup into a work_struct.<br /> <br /> Since get_current_rng() no longer returns ERR_PTR values, the IS_ERR()<br /> checks are removed from its callers.<br /> <br /> With hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can no<br /> longer clear hwrng_fill itself. Therefore, if hwrng_fillfn() returns<br /> directly after current_rng is dropped, kthread_stop() would be called on<br /> a freed task_struct later. To fix this, hwrng_fillfn() calls schedule()<br /> now to keep the task alive until being stopped. The kthread_stop() call<br /> is also moved from hwrng_unregister() to drop_current_rng(), ensuring<br /> kthread_stop() is called on all possible paths where current_rng becomes<br /> NULL, so that the thread would not wait forever.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix memory leak in ext4_ext_shift_extents()<br /> <br /> In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the<br /> function returns immediately without releasing the path obtained via<br /> ext4_find_extent(), leading to a memory leak.<br /> <br /> Fix this by jumping to the out label to ensure the path is properly<br /> released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc()<br /> <br /> In amdgpu_acpi_enumerate_xcc(), if amdgpu_acpi_dev_init() returns -ENOMEM,<br /> the function returns directly without releasing the allocated xcc_info,<br /> resulting in a memory leak.<br /> <br /> Fix this by ensuring that xcc_info is properly freed in the error paths.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: ab8500: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Commit 1c1f13a006ed ("power: supply: ab8500: Move to componentized<br /> binding") introduced this issue during a refactorization. Fix this racy<br /> use-after-free by making sure the IRQ is requested _after_ the<br /> registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix race condition during PASID entry replacement<br /> <br /> The Intel VT-d PASID table entry is 512 bits (64 bytes). When replacing<br /> an active PASID entry (e.g., during domain replacement), the current<br /> implementation calculates a new entry on the stack and copies it to the<br /> table using a single structure assignment.<br /> <br /> struct pasid_entry *pte, new_pte;<br /> <br /> pte = intel_pasid_get_entry(dev, pasid);<br /> pasid_pte_config_first_level(iommu, &amp;new_pte, ...);<br /> *pte = new_pte;<br /> <br /> Because the hardware may fetch the 512-bit PASID entry in multiple<br /> 128-bit chunks, updating the entire entry while it is active (Present<br /> bit set) risks a "torn" read. In this scenario, the IOMMU hardware<br /> could observe an inconsistent state — partially new data and partially<br /> old data — leading to unpredictable behavior or spurious faults.<br /> <br /> Fix this by removing the unsafe "replace" helpers and following the<br /> "clear-then-update" flow, which ensures the Present bit is cleared and<br /> the required invalidation handshake is completed before the new<br /> configuration is applied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Clear Present bit before tearing down context entry<br /> <br /> When tearing down a context entry, the current implementation zeros the<br /> entire 128-bit entry using multiple 64-bit writes. This creates a window<br /> where the hardware can fetch a "torn" entry — where some fields are<br /> already zeroed while the &amp;#39;Present&amp;#39; bit is still set — leading to<br /> unpredictable behavior or spurious faults.<br /> <br /> While x86 provides strong write ordering, the compiler may reorder writes<br /> to the two 64-bit halves of the context entry. Even without compiler<br /> reordering, the hardware fetch is not guaranteed to be atomic with<br /> respect to multiple CPU writes.<br /> <br /> Align with the "Guidance to Software for Invalidations" in the VT-d spec<br /> (Section 6.5.3.3) by implementing the recommended ownership handshake:<br /> <br /> 1. Clear only the &amp;#39;Present&amp;#39; (P) bit of the context entry first to<br /> signal the transition of ownership from hardware to software.<br /> 2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.<br /> 3. Perform the required cache and context-cache invalidation to ensure<br /> hardware no longer has cached references to the entry.<br /> 4. Fully zero out the entry only after the invalidation is complete.<br /> <br /> Also, add a dma_wmb() to context_set_present() to ensure the entry<br /> is fully initialized before the &amp;#39;Present&amp;#39; bit becomes visible.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix inline data read failure for ztailpacking pclusters<br /> <br /> Compressed folios for ztailpacking pclusters must be valid before adding<br /> these pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster()<br /> may assume they are already valid and then trigger a NULL pointer<br /> dereference.<br /> <br /> It is somewhat hard to reproduce because the inline data is in the same<br /> block as the tail of the compressed indexes, which are usually read just<br /> before. However, it may still happen if a fatal signal arrives while<br /> read_mapping_folio() is running, as shown below:<br /> <br /> erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> <br /> ...<br /> <br /> pc : z_erofs_decompress_queue+0x4c8/0xa14<br /> lr : z_erofs_decompress_queue+0x160/0xa14<br /> sp : ffffffc08b3eb3a0<br /> x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000<br /> x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001<br /> x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700<br /> x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098<br /> x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004<br /> x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9<br /> x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f<br /> x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020<br /> x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> z_erofs_decompress_queue+0x4c8/0xa14<br /> z_erofs_runqueue+0x908/0x97c<br /> z_erofs_read_folio+0x128/0x228<br /> filemap_read_folio+0x68/0x128<br /> filemap_get_pages+0x44c/0x8b4<br /> filemap_read+0x12c/0x5b8<br /> generic_file_read_iter+0x4c/0x15c<br /> do_iter_readv_writev+0x188/0x1e0<br /> vfs_iter_read+0xac/0x1a4<br /> backing_file_read_iter+0x170/0x34c<br /> ovl_read_iter+0xf0/0x140<br /> vfs_read+0x28c/0x344<br /> ksys_read+0x80/0xf0<br /> __arm64_sys_read+0x24/0x34<br /> invoke_syscall+0x60/0x114<br /> el0_svc_common+0x88/0xe4<br /> do_el0_svc+0x24/0x30<br /> el0_svc+0x40/0xa8<br /> el0t_64_sync_handler+0x70/0xbc<br /> el0t_64_sync+0x1bc/0x1c0<br /> <br /> Fix this by reading the inline data before allocating and adding<br /> the pclusters to the I/O chains.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix e4b bitmap inconsistency reports<br /> <br /> A bitmap inconsistency issue was observed during stress tests under<br /> mixed huge-page workloads. Ext4 reported multiple e4b bitmap check<br /> failures like:<br /> <br /> ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as<br /> per group info. But got 8192 blocks<br /> <br /> Analysis and experimentation confirmed that the issue is caused by a<br /> race condition between page migration and bitmap modification. Although<br /> this timing window is extremely narrow, it is still hit in practice:<br /> <br /> folio_lock ext4_mb_load_buddy<br /> __migrate_folio<br /> check ref count<br /> folio_mc_copy __filemap_get_folio<br /> folio_try_get(folio)<br /> ......<br /> mb_mark_used<br /> ext4_mb_unload_buddy<br /> __folio_migrate_mapping<br /> folio_ref_freeze<br /> folio_unlock<br /> <br /> The root cause of this issue is that the fast path of load_buddy only<br /> increments the folio&amp;#39;s reference count, which is insufficient to prevent<br /> concurrent folio migration. We observed that the folio migration process<br /> acquires the folio lock. Therefore, we can determine whether to take the<br /> fast path in load_buddy by checking the lock status. If the folio is<br /> locked, we opt for the slow path (which acquires the lock) to close this<br /> concurrency window.<br /> <br /> Additionally, this change addresses the following issues:<br /> <br /> When the DOUBLE_CHECK macro is enabled to inspect bitmap-related<br /> issues, the following error may be triggered:<br /> <br /> corruption in group 324 at byte 784(6272): f in copy != ff on<br /> disk/prealloc<br /> <br /> Analysis reveals that this is a false positive. There is a specific race<br /> window where the bitmap and the group descriptor become momentarily<br /> inconsistent, leading to this error report:<br /> <br /> ext4_mb_load_buddy ext4_mb_load_buddy<br /> __filemap_get_folio(create|lock)<br /> folio_lock<br /> ext4_mb_init_cache<br /> folio_mark_uptodate<br /> __filemap_get_folio(no lock)<br /> ......<br /> mb_mark_used<br /> mb_mark_used_double<br /> mb_cmp_bitmaps<br /> mb_set_bits(e4b-&gt;bd_bitmap)<br /> folio_unlock<br /> <br /> The original logic assumed that since mb_cmp_bitmaps is called when the<br /> bitmap is newly loaded from disk, the folio lock would be sufficient to<br /> prevent concurrent access. However, this overlooks a specific race<br /> condition: if another process attempts to load buddy and finds the folio<br /> is already in an uptodate state, it will immediately begin using it without<br /> holding folio lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure<br /> <br /> get_burstcount() can return -EBUSY on timeout. When this happens, the<br /> function returns directly without releasing the locality that was<br /> acquired at the beginning of tpm_tis_i2c_send().<br /> <br /> Use goto out_err to ensure proper cleanup when get_burstcount() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: fix oops when split header is enabled<br /> <br /> For GMAC4, when split header is enabled, in some rare cases, the<br /> hardware does not fill buf2 of the first descriptor with payload.<br /> Thus we cannot assume buf2 is always fully filled if it is not<br /> the last descriptor. Otherwise, the length of buf2 of the second<br /> descriptor will be calculated wrong and cause an oops:<br /> <br /> Unable to handle kernel paging request at virtual address ffff00019246bfc0<br /> ...<br /> x2 : 0000000000000040 x1 : ffff00019246bfc0 x0 : ffff00009246c000<br /> Call trace:<br /> dcache_inval_poc+0x28/0x58 (P)<br /> dma_direct_sync_single_for_cpu+0x38/0x6c<br /> __dma_sync_single_for_cpu+0x34/0x6c<br /> stmmac_napi_poll_rx+0x8f0/0xb60<br /> __napi_poll.constprop.0+0x30/0x144<br /> net_rx_action+0x160/0x274<br /> handle_softirqs+0x1b8/0x1fc<br /> ...<br /> <br /> To fix this, the PL bit-field in RDES3 register is used for all<br /> descriptors, whether it is the last descriptor or not.