Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - use print_hex_dump_devel to guard key hex dumps<br /> <br /> Use print_hex_dump_devel() for dumping sensitive key material in<br /> *_setkey() and gen_split_key() to avoid leaking secrets at runtime when<br /> CONFIG_DYNAMIC_DEBUG is enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()<br /> <br /> scmi_regulator_probe() calls of_find_node_by_name() which takes a<br /> reference on the returned device node. On the error path where<br /> process_scmi_regulator_of_node() fails, the function returns without<br /> calling of_node_put() on the child node, leaking the reference.<br /> <br /> Add of_node_put(np) on the error path to properly release the<br /> reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Fix freeing of PMD-sized vmemmap pages<br /> <br /> Commit bf9e4e30f353 ("x86/mm: use pagetable_free()"), switched from<br /> freeing non-boot page tables through __free_pages() to<br /> pagetable_free().<br /> <br /> However, the function is also called to free vmemmap pages.<br /> <br /> Given that vmemmap pages are not page tables, already the page_ptdesc(page)<br /> is wrong. But worse, pagetable_free() calls:<br /> <br /> __free_pages(page, compound_order(page));<br /> <br /> Since vmemmap pages are not compound pages (see vmemmap_alloc_block())<br /> -- except for HVO, which doesn&amp;#39;t apply here -- only first page of a<br /> PMD-sized vmemmap page is freed, leaking the other ones.<br /> <br /> Fix it by properly decoupling pagetable and vmemmap freeing.<br /> free_pagetable() no longer has to mess with SECTION_INFO, as only the<br /> vmemmap is marked like that in register_page_bootmem_memmap().<br /> <br /> The indentation in remove_pmd_table() is messed up. Fix that while<br /> touching it.<br /> <br /> Bootmem info handling will soon be fixed up. For now, handle it<br /> similar to free_pagetable(), just avoiding the ifdef.<br /> <br /> [ dhansen: changelog munging. More imperative voice ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fsl-lpspi: terminate the RX channel on TX prepare failure path<br /> <br /> When dmaengine_prep_slave_sg() fails for the TX channel, the error path<br /> terminates the TX DMA channel but leaves the RX channel running. Since<br /> the RX channel was already submitted and issued prior to preparing<br /> the TX descriptor, returning -EINVAL causes the SPI core to unmap the<br /> DMA buffers while the RX DMA engine continues writing to them, leading<br /> to potential memory corruption or use-after-free.<br /> <br /> Terminate the RX channel before returning on the TX prepare failure path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - validate RSA CRT component lengths<br /> <br /> The generic RSA key parser (rsa_helper.c) bounds each CRT component (p,<br /> q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt()<br /> allocates half-size DMA buffers (key_sz / 2) and right-aligns each<br /> component with:<br /> <br /> memcpy(dst + half_key_sz - len, src, len)<br /> <br /> When a CRT component is larger than half_key_sz the subtraction<br /> underflows and memcpy writes past the DMA buffer, causing memory<br /> corruption.<br /> <br /> Add a len &gt; half_key_sz check next to the existing !len check for each<br /> of the five CRT components so the driver falls back to the non-CRT path<br /> instead of writing out of bounds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - protect service table iterations with service_lock<br /> <br /> The service_table list is protected by service_lock when entries are<br /> added or removed (in adf_service_add() and adf_service_remove()), but<br /> several functions iterate over the list without holding this lock.<br /> <br /> A concurrent adf_service_register() or adf_service_unregister() call<br /> could modify the list during traversal, leading to list corruption or<br /> a use-after-free.<br /> <br /> Fix this by holding service_lock across all list_for_each_entry()<br /> iterations of service_table in adf_dev_init(), adf_dev_start(),<br /> adf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(),<br /> adf_dev_restarted_notify(), and adf_error_notifier().<br /> <br /> The lock ordering is safe: callers of the static helpers (adf_dev_up()<br /> and adf_dev_down()) acquire state_lock before service_lock, and no<br /> event_hld callback or service_lock holder ever acquires state_lock in<br /> the reverse order.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: drbg - Fix returning success on failure in CTR_DRBG<br /> <br /> drbg_ctr_generate() sometimes returns success when it fails, leaving the<br /> output buffer uninitialized. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG)<br /> <br /> Sashiko notes:<br /> <br /> &gt; if SEV initialization fails and KVM is actively running normal VMs, could a<br /> &gt; userspace process trigger this code path via /dev/sev ioctls (e.g.,<br /> &gt; SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN<br /> &gt; execution for an active VM trigger a general protection fault and crash the<br /> &gt; host?<br /> <br /> Refuse to re-try initialization if SNP is not already initialized for<br /> SNP_CONFIG.<br /> <br /> This is technically an ABI break: before if SNP initialization failed it<br /> could be transparently retriggered by this ioctl, and if no VMs were<br /> running, everything worked fine. Hopefully this is enough of a corner case<br /> that nobody will notice, but someone does, there are a few options:<br /> <br /> * do something like symbol_get() for kvm and refuse to initialize if KVM is<br /> loaded<br /> * check each cpu&amp;#39;s HSAVE_PA for non-zero data before re-initializing<br /> * once initialization has failed, continue to refuse to initialize until<br /> the ccp module is unloaded

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD)<br /> <br /> Sashiko notes:<br /> <br /> &gt; if SEV initialization fails and KVM is actively running normal VMs, could a<br /> &gt; userspace process trigger this code path via /dev/sev ioctls (e.g.,<br /> &gt; SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN<br /> &gt; execution for an active VM trigger a general protection fault and crash the<br /> &gt; host?<br /> <br /> The SEV firmware docs for SNP_VLEK_LOAD note:<br /> <br /> &gt; On SNP_SHUTDOWN, the VLEK is deleted.<br /> <br /> That is, the initialization/shutdown wrapper here is pointless, because the<br /> firmware immediately throws away the key anyway. Instead, refuse to do<br /> anything if SNP has not been previously initialized.<br /> <br /> This is an ABI break: before, this was a no-op and almost certainly a<br /> mistake by userspace, and now it returns -ENODEV. ABI compatibility could be<br /> maintained here by simply returning 0 in the check instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Use sizeof(*hdr) instead of sizeof(hdr) in veventq read<br /> <br /> The bound-check in iommufd_veventq_fops_read() for the normal vEVENT<br /> path uses sizeof(hdr) where the surrounding code uses sizeof(*hdr):<br /> <br /> if (!vevent_for_lost_events_header(cur) &amp;&amp;<br /> sizeof(hdr) + cur-&gt;data_len &gt; count - done) {<br /> <br /> hdr is declared as struct iommufd_vevent_header *, so sizeof(hdr)<br /> evaluates to the size of the pointer. Surrounding code uses<br /> sizeof(*hdr) consistently:<br /> <br /> if (done &gt;= count || sizeof(*hdr) &gt; count - done) {<br /> ...<br /> if (copy_to_user(buf + done, hdr, sizeof(*hdr))) {<br /> ...<br /> done += sizeof(*hdr);<br /> <br /> struct iommufd_vevent_header is currently 8 bytes (two __u32 fields,<br /> flags and sequence), so on 64-bit (sizeof(void *) == 8) the two<br /> expressions happen to be equal and the check works as intended.<br /> <br /> On 32-bit (sizeof(void *) == 4) the check under-counts the header by<br /> 4 bytes: a vEVENT whose data_len causes 8 + cur-&gt;data_len to exceed<br /> count - done while 4 + cur-&gt;data_len does not will pass the check,<br /> then the loop will copy_to_user 8 bytes of header followed by data_len<br /> bytes of payload, writing past the user-supplied buffer.<br /> <br /> It is also a latent bug for any future expansion of struct<br /> iommufd_vevent_header beyond sizeof(void *) on 64-bit; the check<br /> should not depend on the type happening to match the host pointer<br /> width.<br /> <br /> Use sizeof(*hdr) to match the rest of the function and the actual<br /> amount that will be copied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: do file ownership checks with the proper mount idmap<br /> <br /> Ever since idmapped mounts were introduced, inode ownership checks (for<br /> side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done<br /> against the nop_mnt_idmap, which completely ignores the file&amp;#39;s mount&amp;#39;s<br /> idmap. This results in odd edgecases like:<br /> <br /> 1) mount/bind-mount with an idmap userA:userB:1<br /> 2) userB runs an owner_or_capable() check on file that is owned by userA<br /> on-disk/in-memory, but owned by userB after idmap translation<br /> 3) owner_or_capable() mysteriously fails as the correct idmap wasn&amp;#39;t supplied<br /> <br /> In the case of mincore/madvise MADV_PAGEOUT, this is usually benign,<br /> because file_permission(file, MAY_WRITE) will probably succeed, as it uses<br /> the proper idmap internally, but it does not need to be the case on e.g a<br /> 0444 file where even the owner itself doesn&amp;#39;t have permissions to write to<br /> it.<br /> <br /> Since this is clearly not trivial to get right, introduce a<br /> file_owner_or_capable() that can carry the correct semantics, and switch<br /> the various users in mm to it.<br /> <br /> The issue was found by manual code inspection &amp; an off-list discussion<br /> with Jan Kara.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access<br /> <br /> The page_ext iteration API does not validate if the PFN still belongs to a<br /> valid section while advancing the iterator. When dynamically adding<br /> memory in the hotplug path, it can lead to a NULL pointer dereference<br /> during page_ext_lookup at the boundary of the last valid section when<br /> iterator count equals __pgcount.<br /> <br /> The for_each_page_ext() macro calls page_ext_iter_next() as its loop<br /> increment. for_each_page_ext() does a "__page_ext =<br /> page_ext_iter_next(&amp;__iter)" at the end. This causes page_ext_iter_next()<br /> to increment iter-&gt;index past __pgcount and call page_ext_lookup(start_pfn<br /> + __pgcount). During memory hotplug (online), the PFN at start_pfn +<br /> __pgcount may belong to a section that has not yet been initialized,<br /> causing page_ext_lookup() to trigger a NULL pointer dereference.<br /> <br /> [ 14.555124][ T846] Call trace:<br /> [ 14.555125][ T846] lookup_page_ext+0x6c/0x108 (P)<br /> [ 14.555127][ T846] page_ext_lookup+0x30/0x3c<br /> [ 14.555129][ T846] __reset_page_owner+0x11c/0x260<br /> [ 14.571201][ T846] __free_pages_ok+0x5e8/0x8e0<br /> [ 14.571204][ T846] __free_pages_core+0x78/0xf0<br /> [ 14.571206][ T846] generic_online_page+0x14/0x24<br /> [ 14.597782][ T846] online_pages+0x178/0x30c<br /> [ 14.597784][ T846] memory_block_change_state+0x284/0x32c<br /> [ 14.597787][ T846] memory_subsys_online+0x4c/0x64<br /> [ 14.597789][ T846] device_online+0x88/0xb0<br /> [ 14.597791][ T846] online_memory_block+0x30/0x40<br /> [ 14.597793][ T846] walk_memory_blocks+0xac/0xe8<br /> [ 14.597794][ T846] add_memory_resource+0x280/0x298<br /> [ 14.656161][ T846] add_memory+0x60/0x98<br /> <br /> Move the iteration boundary enforcement inside the iterator functions, so<br /> callers cannot inadvertently access beyond the requested range.