Vulnerabilidades

*** 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 *** A vulnerability in Apache Kvrocks.<br /> <br /> This issue affects Apache Kvrocks: from 2.2.0 through 2.15.0.<br /> <br /> Users are recommended to upgrade to version 2.16.0, which fixes the issue.

*** Pendiente de traducción *** Redis Lua HEAP overflow in cjson library vulnerability in Apache Kvrocks.<br /> <br /> This issue affects Apache Kvrocks: from 2.0.4 through 2.15.0.<br /> <br /> Users are recommended to upgrade to version 2.16.0, which fixes the issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: fix potential unbounded skb queue<br /> <br /> virtio_transport_inc_rx_pkt() checks vvs-&gt;rx_bytes + len &gt; vvs-&gt;buf_alloc.<br /> <br /> virtio_transport_recv_enqueue() skips coalescing for packets<br /> with VIRTIO_VSOCK_SEQ_EOM.<br /> <br /> If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,<br /> a very large number of packets can be queued<br /> because vvs-&gt;rx_bytes stays at 0.<br /> <br /> Fix this by estimating the skb metadata size:<br /> <br /> (Number of skbs in the queue) * SKB_TRUESIZE(0)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: require Ethernet MAC header before using eth_hdr()<br /> <br /> `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and<br /> `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)`<br /> after either assuming that the skb is associated with an Ethernet<br /> device or checking only that the `ETH_HLEN` bytes at<br /> `skb_mac_header(skb)` lie between `skb-&gt;head` and `skb-&gt;data`.<br /> <br /> Make these paths first verify that the skb is associated with an<br /> Ethernet device, that the MAC header was set, and that it spans at<br /> least a full Ethernet header before accessing `eth_hdr(skb)`.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Clamp VBIOS HDMI retimer register count to array size<br /> <br /> [Why &amp; How]<br /> The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and<br /> Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C<br /> register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9]<br /> and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated<br /> before use, so a malformed VBIOS can specify values up to 255, causing an<br /> out-of-bounds heap write during driver probe.<br /> <br /> Clamp each register count to the destination array size using min_t()<br /> before the copy loops, in both get_integrated_info_v11() and<br /> get_integrated_info_v2_1().<br /> <br /> (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs<br /> <br /> [Why &amp; How]<br /> dp_sdp_message_debugfs_write() dereferences connector-&gt;base.state-&gt;crtc<br /> without checking for NULL. A connector can be connected but not bound to<br /> any CRTC (e.g. after hot-plug before the next atomic commit), causing a<br /> kernel crash when writing to the sdp_message debugfs node.<br /> <br /> The function also ignores the user-provided size argument and always<br /> passes 36 bytes to copy_from_user(), reading past the user buffer when<br /> size base.state or state-&gt;crtc is NULL<br /> - Clamping write_size to min(size, sizeof(data))<br /> <br /> (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_fib: fix stale stack leak via the OIFNAME register<br /> <br /> For NFT_FIB_RESULT_OIFNAME the destination register is declared with<br /> len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail,<br /> RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one<br /> register via "*dest = 0". The remaining three registers are left as<br /> whatever was on the stack in nft_do_chain()&amp;#39;s struct nft_regs, and a<br /> downstream expression that loads the register span can leak that<br /> uninitialised kernel stack to userspace.<br /> <br /> The NFTA_FIB_F_PRESENT existence check has the same shape: it is only<br /> meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type<br /> while the eval stores a single byte via nft_reg_store8(), leaving the rest<br /> of the declared span stale.<br /> <br /> Fix both:<br /> <br /> - replace the bare "*dest = 0" in the eval with nft_fib_store_result(),<br /> which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already<br /> used on the other early-return path), and<br /> <br /> - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its<br /> destination as a single u8, so the marked span matches the one byte<br /> the eval writes.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/umem: Fix truncation for block sizes &gt;= 4G<br /> <br /> When the iommu is used the linearization of the mapping can give a single<br /> block that is very large split across multiple SG entries.<br /> <br /> When __rdma_block_iter_next() reassembles the split SG entries it is<br /> overflowing the 32 bit stack values and computed the wrong DMA addresses<br /> for blocks after the truncation.<br /> <br /> Use the right types to hold DMA addresses.

*** Pendiente de traducción *** Improper Handling of Insufficient Permissions or Privileges vulnerability in Apache Kvrocks.<br /> <br /> This issue affects Apache Kvrocks: 2.8.0.<br /> <br /> Users are recommended to upgrade to version 2.16.0, which fixes the issue.

*** Pendiente de traducción *** Relative Path Traversal vulnerability in Apache Kvrocks.<br /> <br /> This issue affects Apache Kvrocks: from 1.0.0 through 2.15.0.<br /> <br /> Users are recommended to upgrade to version 2.16.0, which fixes the issue.