Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> partitions: aix: bound the pp_count scan to the ppe array<br /> <br /> aix_partition() reads the physical volume descriptor into a fixed-size<br /> struct pvd and then scans its physical-partition-extent array:<br /> <br /> int numpps = be16_to_cpu(pvd-&gt;pp_count);<br /> ...<br /> for (i = 0; i ppe + i;<br /> ...<br /> lp_ix = be16_to_cpu(p-&gt;lp_ix);<br /> <br /> pvd points at a single kmalloc()&amp;#39;d struct pvd whose ppe[] member holds a<br /> fixed ARRAY_SIZE(pvd-&gt;ppe) (1016) entries, but the loop runs up to the<br /> on-disk pp_count. pp_count is an unvalidated __be16 read straight from<br /> the descriptor, so a crafted AIX image with pp_count larger than 1016<br /> drives the loop to read pvd-&gt;ppe[i] past the end of the allocation (up<br /> to 65535 entries, ~2 MB out of bounds).<br /> <br /> The partition scan runs without mounting anything, when a block device<br /> with a crafted AIX/IBM partition table appears (an attacker-supplied<br /> image attached with losetup -P, or a device auto-scanned by udev), via<br /> msdos_partition() -&gt; aix_partition().<br /> <br /> Clamp the scan to the number of entries the ppe[] array can hold.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-auth: validate reply message payload bounds against transfer length<br /> <br /> nvmet_auth_reply() accesses the variable-length rval[] array using<br /> attacker-controlled hl (hash length) and dhvlen (DH value length) fields<br /> without verifying they fit within the allocated buffer of tl bytes.<br /> <br /> A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a<br /> small transfer length but large hl/dhvlen values, causing out-of-bounds<br /> heap reads when the target processes the DH public key (rval + 2*hl) or<br /> performs the host response memcmp.<br /> <br /> With DH authentication configured, the OOB pointer is passed directly to<br /> sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching<br /> up to 526 bytes past the buffer. This is exploitable pre-authentication.<br /> <br /> Add bounds validation ensuring sizeof(*data) + 2*hl + dhvlen

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page<br /> <br /> nvmet_execute_disc_get_log_page() validates only the dword alignment<br /> of the host-supplied Log Page Offset (lpo). The 64-bit offset is then<br /> added to a small kzalloc&amp;#39;d buffer that holds the discovery log page<br /> and the result is passed straight to nvmet_copy_to_sgl(), which<br /> memcpy()s data_len bytes out to the host with no source-side bound<br /> check:<br /> <br /> u64 offset = nvmet_get_log_page_offset(req-&gt;cmd); /* 64-bit host */<br /> size_t data_len = nvmet_get_log_page_len(req-&gt;cmd); /* 32-bit host */<br /> ...<br /> if (offset &amp; 0x3) { ... } /* only check */<br /> ...<br /> alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);<br /> buffer = kzalloc(alloc_len, GFP_KERNEL);<br /> ...<br /> status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);<br /> <br /> The Discovery controller is unauthenticated -- nvmet_host_allowed()<br /> returns true unconditionally for the discovery subsystem -- so the call<br /> is reachable pre-authentication by any TCP/RDMA/FC peer that can reach<br /> the nvmet target. With a discovery log page of ~1 KiB, an attacker<br /> requesting up to 4 KiB starting at offset == alloc_len reads the next<br /> slab page out and gets its content returned over the fabric (an<br /> empirical run on a default nvmet-tcp loopback target leaked 81<br /> canonical kernel pointers in one Get Log Page response). Pointing the<br /> offset at unmapped kernel memory faults the in-kernel memcpy and<br /> crashes (or panics, on panic_on_oops=1) the target host instead.<br /> <br /> The attacker-controlled source-side offset pattern<br /> "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique<br /> to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every<br /> other Get Log Page handler in admin-cmd.c either ignores lpo (and<br /> silently starts every response at offset 0) or tracks a local<br /> destination offset with a fixed source pointer.<br /> <br /> Validate the host-supplied offset against the log page size, cap the<br /> copy length to what is actually available, and zero-fill any remainder<br /> of the host transfer buffer. The zero-fill matches the existing<br /> short-response pattern in nvmet_execute_get_log_changed_ns()<br /> (admin-cmd.c) and prevents leaking transport SGL contents when the<br /> host asks for more bytes than the log page contains.

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 /> 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 /> 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: 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: 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.