Vulnerabilidades

*** 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@]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU<br /> <br /> flush_hyp_vcpu() copies the host vCPU context into the hyp&amp;#39;s private<br /> vCPU on every run. ctxt_to_vcpu() expects a guest context to have a<br /> NULL __hyp_running_vcpu, which is only ever set on the host context, so<br /> that it resolves the vCPU via container_of(). While this is generally<br /> the case, flush_hyp_vcpu() copies the context verbatim and does not<br /> enforce this, so a value provided by the host is dereferenced at EL2<br /> (host -&gt; EL2).<br /> <br /> Fix by clearing __hyp_running_vcpu after the copy.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU<br /> <br /> flush_hyp_vcpu() copies the host vGIC state into the hyp&amp;#39;s private vCPU<br /> on every run. The vGIC list register save and restore use used_lrs as<br /> their loop bound and expect it to stay within the number of implemented<br /> list registers. While this is generally the case, flush_hyp_vcpu()<br /> copies vgic_v3 verbatim and does not enforce this, so a value provided<br /> by the host is used at EL2 to index vgic_lr[] and access ICH_LR_EL2<br /> (host -&gt; EL2).<br /> <br /> Fix by clamping used_lrs to the number of implemented list registers<br /> after the copy, as the trusted path already does in<br /> vgic_flush_lr_state(). The number of implemented list registers is<br /> constant after init, so it is replicated once from<br /> kvm_vgic_global_state.nr_lr into hyp_gicv3_nr_lr rather than read on<br /> every entry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB<br /> <br /> VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions,<br /> and either can race against a vcpu not being onlined yet (no pseudo-TLB<br /> allocated). Similarly, the TLB might be invalid, and the invalidation<br /> should be skipped in this case.<br /> <br /> Both kvm_invalidate_vncr_ipa() and kvm_invalidate_vncr_va() are<br /> expected to perform the same checks, except that the latter doesn&amp;#39;t<br /> check for the allocation and blindly dereferences the pointer.<br /> <br /> Solve this by introducing a new iterator built on top of the usual<br /> kvm_for_each_vcpu() that checks for both of the above conditions,<br /> and convert the two users to it.