Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Bound root directory content to block size<br /> <br /> __tb_property_parse_dir() does not check that content_offset +<br /> content_len fits within block_len for the root directory case.<br /> When rootdir-&gt;length equals or exceeds block_len - 2, the entry<br /> loop reads past the allocated property block.<br /> <br /> Add a bounds check after computing content_offset and content_len<br /> to reject directories whose content extends past the block.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Validate XDomain request packet size before type cast<br /> <br /> tb_xdp_handle_request() casts the received packet buffer to<br /> protocol-specific structs without verifying that the allocation<br /> is large enough for the target type. A peer can send a minimal<br /> XDomain packet that passes the generic header length check but is<br /> shorter than the struct accessed after the cast, causing out-of-<br /> bounds reads from the kmemdup allocation.<br /> <br /> Plumb the packet length through xdomain_request_work and validate<br /> it against the expected struct size before each cast.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: use correct flags for device private PMD entry<br /> <br /> Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support<br /> device-private entries") updated set_pmd_migration_entry() to use<br /> pmdp_huge_get_and_clear() in the softleaf case, but made no further<br /> adjustments to the function itself.<br /> <br /> Therefore this function continues to incorrectly use pmd_write(),<br /> pmd_soft_dirty() and pmd_uffd_wp() to determine whether the installed<br /> migration entry should be marked writable, softdirty or uffd-wp<br /> respectively.<br /> <br /> Whilst all are incorrect, the most problematic of these is pmd_write(), as<br /> this can lead to corrupted rmap state.<br /> <br /> On x86-64 _PAGE_SWP_SOFT_DIRTY is aliased to _PAGE_RW. So calling<br /> pmd_write() on a softleaf will return the softdirty state encoded in the<br /> entry, assuming CONFIG_MEM_SOFT_DIRTY was enabled.<br /> <br /> This was observed when running the hmm.hmm_device_private.anon_write_child<br /> selftest:<br /> <br /> 1. The test faults in a range then migrates it such that a device-private<br /> THP range is established.<br /> <br /> 2. The parent then migrates it to a device-private writable PMD entry whose<br /> folio is entirely AnonExclusive with entire_mapcount=1, softdirty set<br /> (accidentally correct write state).<br /> <br /> 3. The parent forks and the PMD entries are set to device-private read only<br /> entries, entire_mapcount=2, softdirty still set.<br /> <br /> 4. [BUG] The child writes to the range then migrates to RAM - intending to<br /> install non-writable migration entries - but replacing parent and child<br /> PMD mappings with WRITABLE entries due to misinterpreting the softdirty<br /> bit.<br /> <br /> 5. In remove_migration_pmd(), if !softleaf_is_migration_read(entry) we<br /> set the RMAP_EXCLUSIVE flag when calling folio_add_anon_rmap_pmd() for<br /> both parent and child, which are therefore AnonExclusive.<br /> <br /> 6. [SPLAT] Child sets migrated folio entire_mapcount=1, parent sets<br /> entire_mapcount=2 and we end up with an AnonExclusive folio with<br /> entire_mapcount=2! Assert fires in __folio_add_anon_rmap():<br /> <br /> VM_WARN_ON_FOLIO(folio_test_large(folio) &amp;&amp;<br /> folio_entire_mapcount(folio) &gt; 1 &amp;&amp;<br /> PageAnonExclusive(cur_page), folio)<br /> <br /> This patch fixes the issue by correctly referencing the softleaf entry<br /> fields for writable, softdirty and uffd-wp in set_pmd_migration_entry().<br /> <br /> It also only updates A/D flags if the entry is present as these are<br /> otherwise not meaningful for a softleaf entry.<br /> <br /> This patch also flips the if (!present) { ... } else { ... } logic in<br /> set_pmd_migration_entry() so it is easier to understand, and adds some<br /> comments to make things clearer.<br /> <br /> I was able to bisect this to commit 775465fd26a3 ("lib/test_hmm: add zone<br /> device private THP test infrastructure") which first exposes this bug as<br /> it was the commit that permitted test_hmm to generate the test.<br /> <br /> However commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support<br /> device-private entries") is the commit that actually enabled this<br /> behaviour.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: restore reservation on error in hugetlb folio copy paths<br /> <br /> Two sites in mm/hugetlb.c allocate a hugetlb folio via<br /> alloc_hugetlb_folio() (consuming a VMA reservation) and then call<br /> copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c<br /> ("mm: hwpoison: support recovery from HugePage copy-on-write faults") and<br /> can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the<br /> failure path, folio_put() restores the global hugetlb pool count through<br /> free_huge_folio(), but the per-VMA reservation map entry is left marked<br /> consumed:<br /> <br /> - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY)<br /> - copy_hugetlb_page_range() fork-time CoW path when<br /> hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon<br /> folio under fork)<br /> <br /> User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the<br /> resubmission copy fails, the reservation for that address is leaked from<br /> the VMA&amp;#39;s reserve map. A subsequent fault at the same address takes the<br /> no-reservation path, and under hugetlb pool pressure the task is SIGBUSed<br /> at an address it had previously reserved. The fork-time CoW path leaks<br /> the same way in the child VMA&amp;#39;s reserve map, though it requires the much<br /> rarer combination of pinned hugetlb anon page + hwpoisoned source.<br /> <br /> Add the missing restore_reserve_on_error() call before folio_put() on both<br /> error paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11<br /> <br /> The v11 MQD manager incorrectly assigned the CP-compute variants of<br /> checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions<br /> use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct<br /> v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow.<br /> <br /> During CRIU checkpoint of an SDMA queue on Navi3x:<br /> - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer,<br /> leaking 1536 bytes of adjacent GTT memory to userspace<br /> <br /> During CRIU restore:<br /> - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer,<br /> corrupting 1536 bytes of adjacent GTT memory (often the ring buffer<br /> or neighboring MQDs)<br /> <br /> This is a copy-paste regression unique to v11. All other ASIC backends<br /> (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants.<br /> <br /> Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly<br /> handle the smaller v11_sdma_mqd structure, matching the pattern used in<br /> other MQD managers.<br /> <br /> (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gem: Try to fix change_handle ioctl, attempt 4<br /> <br /> [airlied: just added some comments on how to reenable]<br /> On-list because the cat is out of the bag and we&amp;#39;re clearly not good<br /> enough to figure this out in private. The story thus far:<br /> <br /> 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in<br /> change_handle") tried to fix a race condition between the gem_close and<br /> gem_change_handle ioctls, but got a few things wrong:<br /> <br /> - There&amp;#39;s a confusion with the local variable handle, which is actually<br /> the new handle, and so the two-stage trick was actually applied to the<br /> wrong idr slot. 7164d78559b0 ("drm/gem: fix race between<br /> change_handle and handle_delete") tried to fix that by adding yet<br /> another code block, but forgot to add the error handling. Which meant<br /> we now have two paths, both kinda wrong.<br /> <br /> - dc366607c41c ("drm: Replace old pointer to new idr") tried to apply<br /> another fix, but inconsistently, again because of the handle confusion<br /> - this would be the right fix (kinda, somewhat, it&amp;#39;s a mess) if we&amp;#39;d<br /> do the two-stage approach for the new handle. Except that wasn&amp;#39;t the<br /> intent of the original fix.<br /> <br /> We also didn&amp;#39;t have an igt merged for the original ioctl, which is a big<br /> no-go. This was attempted to address off-list in the original bugfix,<br /> and amd QA people claimed the bug was fixed now. Very clearly that&amp;#39;s not<br /> the case. Here&amp;#39;s my attempt to sort this out:<br /> <br /> - Rename the local variable to new_handle, the old aliasing with<br /> args-&gt;handle is just too dangerously confusing.<br /> <br /> - Merge the gem obj lookup with the two-stage idr_replace so that we<br /> avoid getting ourselves confused there.<br /> <br /> - This means we don&amp;#39;t have a surplus temporary reference anymore, only<br /> an inherited from the idr. A concurrent gem_close on the new_handle<br /> could steal that. Fix that with the same two-stage approach<br /> create_tail uses. This is a bit overkill as documented in the comment,<br /> but I also don&amp;#39;t trust my ability to understand this all correctly, so<br /> go with the established pattern we have from other ioctls instead for<br /> maximum paranoia.<br /> <br /> - Adjust error paths. I&amp;#39;ve tried to make the error and success paths<br /> common, because they are identical except for which handle is removed<br /> and on which we call idr_replace to (re)install the object again. But<br /> that made things messier to read, so I&amp;#39;ve left it at the more verbose<br /> version, which unfortunately hides the symmetry in the entire code<br /> flow a bit.<br /> <br /> - While at it, also replace the 7 space indent with 1 tab.<br /> <br /> And finally, because I flat out don&amp;#39;t trust my abilities here at all<br /> anymore:<br /> <br /> - Disable the ioctl until we have the igt situation and everything else<br /> sorted out on-list and with full consensus.<br /> <br /> v2:<br /> <br /> Sashiko noticed that I didn&amp;#39;t handle the error path for idr_replace<br /> correctly, it must be checked with IS_ERR_OR_NULL like in<br /> gem_handle_delete. So yeah, definitely should just the existing paths<br /> 1:1 because this is endless amounts of tricky.<br /> <br /> Also add the Fixes: line for the original ioctl, I forgot that too.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Limit XDomain response copy to actual frame size<br /> <br /> tb_xdomain_copy() copies req-&gt;response_size bytes from the received<br /> packet buffer regardless of the actual frame size. When a short<br /> response arrives, this reads past the valid frame data in the DMA<br /> pool buffer into stale contents from previous transactions.<br /> <br /> Use the minimum of frame size and expected response size for the<br /> copy length.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups<br /> <br /> v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect<br /> buffer and the workgroup buffer and is expected to release them before<br /> returning. When any of the workgroup counts read from the buffer is zero,<br /> the function bailed out early and skipped the cleanup, leaking the vaddr<br /> mappings of both BOs.<br /> <br /> Jump to the cleanup path instead of returning directly, so the mappings<br /> are always dropped.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Skip CSD when it has zeroed workgroups<br /> <br /> A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2<br /> registers. Kicking off a dispatch with a zero count in any of the three<br /> dimensions is invalid. First, the hardware will process 0 as 65536,<br /> while the user-space driver exposes a maximum of 65535. Over that, a<br /> submission with a zeroed workgroup dimension should be a no-op.<br /> <br /> These zeroed counts can reach the dispatch path through an indirect CSD<br /> job, whose workgroup counts are only known once the indirect buffer is<br /> read and may legitimately be zero, but such scenario should only result in<br /> a no-op.<br /> <br /> Overwrite the indirect CSD job workgroup counts with the indirect BO<br /> ones, even if they are zeroed, and don&amp;#39;t submit the job to the hardware<br /> when any of the workgroup counts is zero, so the job completes immediately<br /> instead of running the shader.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: fix NULL dereference in get_queue_ids()<br /> <br /> When usr_queue_id_array is NULL and num_queues is non-zero,<br /> get_queue_ids() returns NULL. The callers check only IS_ERR() on the<br /> return value; since IS_ERR(NULL) == false the check passes, and<br /> suspend_queues() calls q_array_invalidate() which immediately<br /> dereferences NULL while iterating num_queues times.<br /> <br /> Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying<br /> num_queues &gt; 0 with a zero queue_array_ptr, causing a kernel panic.<br /> <br /> A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op<br /> (q_array_invalidate never executes, and resume_queues already guards<br /> all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL)<br /> only when num_queues is non-zero and the pointer is absent; both callers<br /> already propagate IS_ERR() returns correctly to userspace.<br /> <br /> (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/display: fix oops in suspend/shutdown without display<br /> <br /> The xe driver keeps track of whether to probe display, and whether<br /> display hardware is there, using xe-&gt;info.probe_display. It gets set to<br /> false if there&amp;#39;s no display after intel_display_device_probe(). However,<br /> the display may also be disabled via fuses, detected at a later time in<br /> intel_display_device_info_runtime_init().<br /> <br /> In this case, the xe driver does for_each_intel_crtc() on uninitialized<br /> mode config in xe_display_flush_cleanup_work(), leading to a NULL<br /> pointer dereference, and generally calls display code with display info<br /> cleared.<br /> <br /> Check for intel_display_device_present() after<br /> intel_display_device_info_runtime_init(), and reset<br /> xe-&gt;info.probe_display as necessary. Also do unset_display_features()<br /> for completeness, although display runtime init has already done<br /> that. This will need to be unified across all cases later.<br /> <br /> Move intel_display_device_info_runtime_init() call slightly earlier,<br /> similar to i915, to avoid a bunch of unnecessary setup for no display<br /> cases.<br /> <br /> Note #1: The xe driver has no business doing low level display plumbing<br /> like for_each_intel_crtc() to begin with. It all needs to happen in<br /> display code.<br /> <br /> Note #2: The actual bug is present already in commit 44e694958b95<br /> ("drm/xe/display: Implement display support"), but the oops was likely<br /> introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display<br /> suspend/resume work on discrete").<br /> <br /> (cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Fix global performance monitor reference counting<br /> <br /> In the SET_GLOBAL ioctl, v3d_perfmon_find() bumps the reference count on<br /> the perfmon it returns, but v3d_perfmon_set_global_ioctl() and<br /> v3d_perfmon_delete() fail to release that reference on several paths:<br /> <br /> 1. v3d_perfmon_set_global_ioctl() leaks the reference on its error<br /> paths.<br /> <br /> 2. CLEAR_GLOBAL leaks both the find reference and the reference<br /> previously stashed in v3d-&gt;global_perfmon by the SET_GLOBAL ioctl<br /> that configured it.<br /> <br /> 3. Destroying a perfmon that is the current global perfmon leaks the<br /> reference stashed by the SET_GLOBAL ioctl.<br /> <br /> Release each of these references explicitly.