Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: target: rdma: fix ndev refcount leak on queue connect<br /> <br /> nvmet_rdma_queue_connect() calls nvmet_rdma_find_get_device() which<br /> acquires a reference on the returned ndev via kref_get(). On the path<br /> where the host queue backlog is exceeded and the function returns<br /> NVME_SC_CONNECT_CTRL_BUSY, reference of ndev is not released, leaking<br /> the kref.<br /> <br /> Fix this by adding a goto to the existing put_device label before the<br /> early return.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: validate sparing table length as an entry count, not a byte count<br /> <br /> udf_load_sparable_map() accepts a sparing table when<br /> <br /> sizeof(*st) + le16_to_cpu(st-&gt;reallocationTableLen) &gt; sb-&gt;s_blocksize<br /> <br /> is false, i.e. it treats reallocationTableLen as a number of BYTES that<br /> must fit in the block. But the table is walked as an array of 8-byte<br /> sparingEntry elements:<br /> <br /> for (i = 0; i reallocationTableLen); i++) {<br /> struct sparingEntry *entry = &amp;st-&gt;mapEntry[i];<br /> ... entry-&gt;origLocation ...<br /> }<br /> <br /> in udf_get_pblock_spar15() and udf_relocate_blocks(). A<br /> reallocationTableLen of N therefore passes the check whenever<br /> sizeof(*st) + N mapEntry[] is an out-of-bounds<br /> write.<br /> <br /> Validate reallocationTableLen as the entry count it is, with<br /> struct_size().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: validate VAT header length against the VAT inode size<br /> <br /> udf_load_vat() takes the virtual partition&amp;#39;s start offset straight from<br /> the on-disk VAT 2.0 header without checking it against the VAT inode<br /> size:<br /> <br /> map-&gt;s_type_specific.s_virtual.s_start_offset =<br /> le16_to_cpu(vat20-&gt;lengthHeader);<br /> map-&gt;s_type_specific.s_virtual.s_num_entries =<br /> (sbi-&gt;s_vat_inode-&gt;i_size -<br /> map-&gt;s_type_specific.s_virtual.s_start_offset) &gt;&gt; 2;<br /> <br /> lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds<br /> the VAT inode size, the s_num_entries subtraction underflows to a huge<br /> count, which defeats the "block &gt; s_num_entries" bound in<br /> udf_get_pblock_virt15(); and on the ICB-inline path that function reads<br /> <br /> ((__le32 *)(iinfo-&gt;i_data + s_start_offset))[block]<br /> <br /> so a large s_start_offset indexes past the inode&amp;#39;s in-ICB data. Mounting<br /> a crafted UDF image with a virtual (VAT) partition then triggers an<br /> out-of-bounds read.<br /> <br /> Reject a VAT whose header length does not leave room for at least one<br /> entry within the VAT inode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: validate free block extents against the partition length<br /> <br /> udf_free_blocks() checks the logical block number and count against the<br /> partition length, but drops the extent offset from that final bound. A<br /> crafted extent can pass the guard while logicalBlockNum + offset + count<br /> points past the partition, which later indexes past the space bitmap<br /> array.<br /> <br /> A single ftruncate(2) on a file backed by such an extent reliably<br /> panics the kernel. This is a local availability issue. On desktop<br /> systems where UDisks/polkit allows the active user to mount removable<br /> UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply<br /> the crafted filesystem and trigger the panic by truncating a writable<br /> file on it. Systems that require root or CAP_SYS_ADMIN to mount the<br /> image have a higher prerequisite.<br /> <br /> No confidentiality or integrity impact is claimed: the reproduced<br /> primitive is an out-of-bounds read of a bitmap pointer slot followed by<br /> a kernel panic.<br /> <br /> Use the already computed logicalBlockNum + offset + count value for the<br /> partition length check. Also make load_block_bitmap() reject an<br /> out-of-range block group before indexing s_block_bitmap[], so corrupted<br /> callers cannot walk past the flexible array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Do not initialize SNP for ioctl(SNP_COMMIT)<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 SNP_COMMIT command does not require the firmware to be in any<br /> particular state. Skip initializing it if it was previously uninitialized.<br /> <br /> The SEV-SNP firmware specification doc 56860 does not mention SNP_COMMIT in<br /> Table 5 as a command that is allowed in the UNINIT state, but it is in fact<br /> allowed and a future documentation update will reflect that.

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.