Vulnerabilidades

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

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Prevent out-of-bounds read in glob matching<br /> <br /> String event fields are not necessarily NUL-terminated, so the filter<br /> predicate functions (filter_pred_string(), filter_pred_strloc() and<br /> filter_pred_strrelloc()) pass the field length to the regex match<br /> callbacks, and the length-aware matchers honour it.<br /> <br /> regex_match_glob() was the exception: it ignored the length and called<br /> glob_match(), which scans the string until it hits a NUL byte. Some<br /> string fields are not NUL-terminated. One example is the dynamic char<br /> array of the xfs_* namespace tracepoints, which is copied without a<br /> trailing NUL. For such a field, glob matching reads past the end of<br /> the event field, causing a KASAN slab-out-of-bounds read in<br /> glob_match(), reached via regex_match_glob() and filter_match_preds()<br /> from the xfs_lookup tracepoint.<br /> <br /> Add a length-bounded glob_match_len() and use it from regex_match_glob()<br /> so glob matching always stops at the field boundary. The matching loop<br /> is factored into a shared helper so glob_match() keeps its behaviour.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/aux: Fix page UAF in map_range()<br /> <br /> map_range() reads rb-&gt;aux_pages[], rb-&gt;aux_nr_pages and rb-&gt;aux_pgoff via<br /> perf_mmap_to_page() while holding only event-&gt;mmap_mutex. Those fields are<br /> serialized by rb-&gt;aux_mutex, and mmap_mutex is per event.<br /> <br /> Thus, two events sharing one rb via PERF_EVENT_IOC_SET_OUTPUT can race<br /> rb_alloc_aux() with map_range(), leading to a page-UAF scenario as follows:<br /> <br /> CPU 0 CPU 1<br /> ===== =====<br /> rb_alloc_aux() map_range()<br /> [1]: allocate rb-&gt;aux_pages[0]<br /> [2]: rb-&gt;aux_nr_pages++<br /> [3]: perf_mmap_to_page()<br /> returns rb-&gt;aux_pages[0]<br /> [4]: map it as VM_PFNMAP<br /> [5]: rb-&gt;aux_pgoff = 1<br /> <br /> munmap the page<br /> [6]: free rb-&gt;aux_pages[0]<br /> <br /> Pages mapped as VM_PFNMAP have no refcount protection, so CPU 1 holds a<br /> mapping to a freed physical frame.<br /> <br /> Fix this by taking rb-&gt;aux_mutex across the page walk in map_range().

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

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

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: bound uniname advance in exfat_find_dir_entry()<br /> <br /> In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the<br /> output pointer by a fixed amount while the loop guard only tracks the<br /> accumulated name length:<br /> <br /> if (++order == 2)<br /> uniname = p_uniname-&gt;name;<br /> else<br /> uniname += EXFAT_FILE_NAME_LEN;<br /> len = exfat_extract_uni_name(ep, entry_uniname);<br /> name_len += len;<br /> unichar = *(uniname+len);<br /> *(uniname+len) = 0x0;<br /> <br /> uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len<br /> grows only by the actual extracted length, which is shorter when a name<br /> fragment contains an early NUL. The only guard is<br /> `name_len &gt;= MAX_NAME_LENGTH`, so a crafted directory with many short<br /> name fragments lets uniname run far past the<br /> p_uniname-&gt;name[MAX_NAME_LENGTH + 3] buffer while name_len stays small,<br /> causing an out-of-bounds read and write at *(uniname+len).<br /> <br /> The sibling extractor exfat_get_uniname_from_ext_entry() already stops<br /> on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard<br /> added in commit d42334578eba ("exfat: check if filename entries exceeds<br /> max filename length")); exfat_find_dir_entry() never got the<br /> equivalent. Track the per-entry write offset as a count and reject a<br /> fragment once the offset, or the offset plus the extracted length, would<br /> exceed MAX_NAME_LENGTH, before forming the output pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> module: decompress: check return value of module_extend_max_pages()<br /> <br /> module_extend_max_pages() calls kvrealloc() internally and returns<br /> -ENOMEM on allocation failure. The return value is never checked.<br /> <br /> If the initial allocation fails, info-&gt;pages remains NULL and<br /> info-&gt;max_pages remains 0. Subsequent calls to module_get_next_page()<br /> will attempt to dynamically grow the array by calling<br /> module_extend_max_pages(info, 0) since info-&gt;used_pages is 0. This<br /> results in kvrealloc(NULL, 0) returning ZERO_SIZE_PTR, which is treated<br /> as a success, leading to a dereference of ZERO_SIZE_PTR and a kernel<br /> oops.<br /> <br /> Fix: add the missing error check after module_extend_max_pages() and<br /> return immediately on failure. This matches the pattern used by every<br /> other kvrealloc() caller in the module loading path.<br /> <br /> [Sami: Corrected the analysis in the commit message.]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: include MAY_WRITE in open permission mask for O_TRUNC<br /> <br /> POSIX requires write permission to truncate a file, so an open() that<br /> specifies O_TRUNC must be authorized for write access regardless of the<br /> O_ACCMODE access mode.<br /> <br /> nfs_open_permission_mask() builds the access mask passed to<br /> nfs_may_open(), which is the local authorization gate for OPENs the<br /> client serves itself from a cached write delegation via the<br /> can_open_delegated() path in nfs4_try_open_cached(). The mask is<br /> derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a<br /> file the caller cannot write requests only MAY_READ and passes the<br /> local check. The OPEN is then satisfied locally and the truncation is<br /> issued to the server as a SETATTR(size=0) over the delegation stateid,<br /> which the server accepts under standard write-delegation semantics.<br /> POSIX requires that this open fail with EACCES.<br /> <br /> Include MAY_WRITE in the mask whenever O_TRUNC is set so the local<br /> check matches the access the server would have enforced.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Ensure vendor&amp;#39;s exit handler runs before fastpath userspace exits<br /> <br /> Move the handling of fastpath userspace exits into vendor code to ensure<br /> KVM runs vendor specific operations that need to run before userspace gains<br /> control of the vCPU. E.g. for VMX (and soon to be for SVM as well), KVM<br /> needs to flush the PML buffer prior to exiting to userspace, otherwise any<br /> memory written by the final KVM_RUN might never be flagged as dirty.<br /> <br /> Note, waiting to snapshot CR0 and CR3 until svm_handle_exit() is flawed in<br /> general, as that risks consuming stale state in a fastpath handler. That<br /> will be addressed in a future change.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Pin source page for write when adding CPUID data for SNP guest<br /> <br /> When populating a guest_memfd instance with the initial CPUID data for an<br /> SNP guest, acquire a writable pin on the source page as KVM will write back<br /> the "correct" CPUID information if the userspace provided data is rejected<br /> by trusted firmware. Because KVM writes to the source page using a kernel<br /> mapping, pinning for read could result in KVM clobbering read-only memory.<br /> <br /> Note, well-behaved VMMs are unlikely to be affected, as CPUID information<br /> is almost always dynamically generated by userspace, i.e. it&amp;#39;s unlikely for<br /> the CPUID information to be backed by a read-only mapping.<br /> <br /> [sean: rewrite shortlog and changelog, tag for stable@]