Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbip: vudc: fix NULL deref in vep_dequeue()<br /> <br /> vep_alloc_request() wasn&amp;#39;t initializing vrequest-&gt;udc, so cancellations<br /> on the FunctionFS AIO path were arriving in vep_dequeue without a valid<br /> UDC reference.<br /> <br /> Since vrequest-&gt;udc is never actually properly used anywhere, we opt to<br /> remove it, and update vep_dequeue to obtain a reference to the udc with<br /> ep_to_vudc(), consistent with the other vep_ ops.<br /> <br /> AFAICT this bug has existed for ~10 years. Seems that nobody has really<br /> stressed the FunctionFS AIO path on usbip&amp;#39;s vudc.<br /> <br /> I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints<br /> via AIO. Before the fix, running `usbip attach` from the host would<br /> cause the guest to oops with the following backtrace:<br /> <br /> Call trace:<br /> vep_dequeue+0x1c/0xe4 (P)<br /> usb_ep_dequeue+0x14/0x20<br /> ffs_aio_cancel+0x24/0x34<br /> __arm64_sys_io_cancel+0xb0/0x124<br /> do_el0_svc+0x68/0x100<br /> el0_svc+0x18/0x5c<br /> el0t_64_sync_handler+0x98/0xdc<br /> el0t_64_sync+0x154/0x158

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: ulpi: fix memory leak on registration failure<br /> <br /> The allocated device name is never freed on early ULPI device<br /> registration failures.<br /> <br /> Fix this by initialising the device structure earlier and releasing the<br /> initial reference whenever registration fails.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isofs: bound Rock Ridge symlink components to the SL record<br /> <br /> get_symlink_chunk() and the SL handling in<br /> parse_rock_ridge_inode_internal() walk the variable-length components of<br /> a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte<br /> header (flags, len) followed by len bytes of text, so it occupies<br /> slp-&gt;len + 2 bytes. Both loops read slp-&gt;len and advance to the next<br /> component, and get_symlink_chunk() additionally does<br /> memcpy(rpnt, slp-&gt;text, slp-&gt;len), but neither checks that the component<br /> lies within the SL record before dereferencing it.<br /> <br /> A crafted SL record whose component declares a len that runs past the<br /> record (rr-&gt;len) therefore triggers an out-of-bounds read of up to 255<br /> bytes. When the record sits at the tail of its backing buffer - for<br /> example a small kmalloc()ed continuation block reached through a CE<br /> record - the read crosses the allocation; get_symlink_chunk() then<br /> copies the out-of-bounds bytes into the symlink body returned to user<br /> space by readlink(), disclosing adjacent kernel memory.<br /> <br /> ISO 9660 images are routinely mounted from untrusted removable media -<br /> desktop environments auto-mount them (e.g. via udisks2) without<br /> CAP_SYS_ADMIN - so the record contents are attacker-controlled.<br /> <br /> Reject any component that does not fit in the remaining record bytes<br /> before using it. In get_symlink_chunk() return NULL, like the existing<br /> output-buffer (plimit) checks, so a malformed record makes readlink()<br /> fail with -EIO rather than silently returning a truncated target; in<br /> parse_rock_ridge_inode_internal() stop the inode-size walk.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.