Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Do not initialize SNP for SEV ioctls<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 /> sev_move_to_init_state() is called for ioctls requiring only SEV firmware:<br /> SEV_PEK_GEN, SEV_PDH_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT, and<br /> SEV_PDH_CERT_EXPORT. After the firmware command, it does SEV_SHUTDOWN on<br /> the SEV firmware. Since these commands do not require SNP to be<br /> initialized, skip it by calling __sev_platform_init_locked() which only<br /> initializes the SEV firmware. This way SNP is not Initialized at all, and<br /> HSAVE_PA is not cleared.<br /> <br /> The previous code saved any SEV initialization firmware error to<br /> init_args.error and then threw it away and hardcoded the return value of<br /> INVALID_PLATFORM_STATE regardless of the real firmware error. This patch<br /> changes it to surface the underlying error, which is hopefully both more<br /> useful and doesn&amp;#39;t cause any problems.<br /> <br /> Note that it is still safe to call __sev_firmware_shutdown() directly: it<br /> calls __sev_snp_shutdown_locked(), which skips SNP shutdown if SNP was not<br /> initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: loongson - Remove broken and unused loongson-rng<br /> <br /> The loongson-rng rng_alg has several vulnerabilities, including not<br /> providing forward security, and a use-after-free bug due to the use of<br /> wait_for_completion_interruptible().<br /> <br /> Meanwhile, the rng_alg framework doesn&amp;#39;t really have any purpose in the<br /> first place other than to access the software algorithms crypto/drbg.c<br /> and crypto/jitterentropy.c. Hardware-specific rng_algs have no<br /> in-kernel user, and unlike hwrng there&amp;#39;s no feed into the actual Linux<br /> RNG. As such, there&amp;#39;s really no point to this code. There are of<br /> course other rng_alg drivers that are similarly unused, but they&amp;#39;re<br /> similarly in the process of being phased out, e.g.<br /> https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and<br /> https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org<br /> <br /> Given that, there&amp;#39;s no point in fixing forward these vulnerabilities,<br /> and it makes much more sense to simply roll back the addition of this<br /> driver. If this platform provides TRNG (not PRNG) functionality, it<br /> could make sense to add a hwrng driver, but it would be quite different.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: pcrypt - restore callback for non-parallel fallback<br /> <br /> pcrypt installs pcrypt_aead_done() on the child AEAD request before<br /> trying to submit it through padata. If padata_do_parallel() returns<br /> -EBUSY, pcrypt falls back to calling the child AEAD directly.<br /> <br /> That fallback must not keep the padata completion callback. Otherwise<br /> an asynchronous completion runs pcrypt_aead_done() even though the<br /> request was never enrolled in padata.<br /> <br /> Restore the original request callback and callback data before calling<br /> the child AEAD directly. This keeps the fallback path aligned with a<br /> direct AEAD request while leaving the parallel path unchanged.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ecc - Fix carry overflow in vli multiplication<br /> <br /> The carry flag calculation fails when r01.m_high is saturated<br /> (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows.<br /> <br /> The condition (r01.m_high

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: chacha20poly1305 - validate poly1305 template argument<br /> <br /> chachapoly_create() still accepts the compatibility poly1305 parameter<br /> in the template name, but it assumes the second template argument is<br /> always present and immediately passes it to strcmp().<br /> <br /> When the argument is missing, crypto_attr_alg_name() returns an error<br /> pointer. Check for that before comparing the name so malformed template<br /> instantiations fail with an error instead of dereferencing the error<br /> pointer in strcmp().<br /> <br /> This matches the surrounding Crypto API template pattern where<br /> crypto_attr_alg_name() results are validated before string-specific use.

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() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG<br /> is enabled.

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.