Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpib: Fix memory leak in ni_usb_init()<br /> <br /> In ni_usb_init(), if ni_usb_setup_init() fails, the function returns<br /> -EFAULT without freeing the allocated writes buffer, leading to a<br /> memory leak.<br /> <br /> Additionally, ni_usb_setup_init() returns 0 on failure, which causes<br /> ni_usb_init() to return -EFAULT, an inappropriate error code for this<br /> situation.<br /> <br /> Fix the leak by freeing writes in the error path. Modify<br /> ni_usb_setup_init() to return -EINVAL on failure and propagate this<br /> error code in ni_usb_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Hold mm structure across iommu_sva_unbind_device()<br /> <br /> Some tests trigger a crash in iommu_sva_unbind_device() due to<br /> accessing iommu_mm after the associated mm structure has been<br /> freed.<br /> <br /> Fix this by taking an explicit reference to the mm structure<br /> after successfully binding the device, and releasing it only<br /> after the device is unbound. This ensures the mm remains valid<br /> for the entire SVA bind/unbind lifetime.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: pm8916_lbc: 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 /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: inside-secure/eip93 - fix kernel panic in driver detach<br /> <br /> During driver detach, the same hash algorithm is unregistered multiple<br /> times due to a wrong iterator.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: goldfish: 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 /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot<br /> <br /> In the &amp;#39;DeleteIndexEntryRoot&amp;#39; case of the &amp;#39;do_action&amp;#39; function, the<br /> entry size (&amp;#39;esize&amp;#39;) is retrieved from the log record without adequate<br /> bounds checking.<br /> <br /> Specifically, the code calculates the end of the entry (&amp;#39;e2&amp;#39;) using:<br /> e2 = Add2Ptr(e1, esize);<br /> <br /> It then calculates the size for memmove using &amp;#39;PtrOffset(e2, ...)&amp;#39;,<br /> which subtracts the end pointer from the buffer limit. If &amp;#39;esize&amp;#39; is<br /> maliciously large, &amp;#39;e2&amp;#39; exceeds the used buffer size. This results in<br /> a negative offset which, when cast to size_t for memmove, interprets<br /> as a massive unsigned integer, leading to a heap buffer overflow.<br /> <br /> This commit adds a check to ensure that the entry size (&amp;#39;esize&amp;#39;) strictly<br /> fits within the remaining used space of the index header before performing<br /> memory operations.