Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-thin: fix metadata refcount underflow<br /> <br /> There&amp;#39;s a bug in dm-thin in the function rebalance_children. If the<br /> internal btree node has one entry, the code tries to copy all btree<br /> entries from the node&amp;#39;s child to the node itself and then decrement the<br /> child&amp;#39;s reference count.<br /> <br /> If the child node is shared (it has reference count &gt; 1), we won&amp;#39;t free<br /> it, so there would be two pointers to each of the grandchildren nodes.<br /> But the reference counts of the grandchildren is not increased, thus the<br /> reference count doesn&amp;#39;t match the number of pointers that point to the<br /> grandchildren. This results in "device mapper: space map common: unable<br /> to decrement block" errors.<br /> <br /> Fix this bug by incrementing reference counts on the grandchildren if the<br /> btree node is shared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: Prevent NULL deref when RX memory exhausted<br /> <br /> The CPU receives frames from the MAC through conventional DMA: the CPU<br /> allocates buffers for the MAC, then the MAC fills them and returns<br /> ownership to the CPU. For each hardware RX queue, the CPU and MAC<br /> coordinate through a shared ring array of DMA descriptors: one<br /> descriptor per DMA buffer. Each descriptor includes the buffer&amp;#39;s<br /> physical address and a status flag ("OWN") indicating which side owns<br /> the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set<br /> the flag and the MAC is only allowed to clear it, and both must move<br /> through the ring in sequence: thus the ring is used for both<br /> "submissions" and "completions."<br /> <br /> In the stmmac driver, stmmac_rx() bookmarks its position in the ring<br /> with the `cur_rx` index. The main receive loop in that function checks<br /> for rx_descs[cur_rx].own=0, gives the corresponding buffer to the<br /> network stack (NULLing the pointer), and increments `cur_rx` modulo the<br /> ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its<br /> position with `dirty_rx`, allocates fresh buffers and rearms the<br /> descriptors (setting OWN=1). If it fails any allocation, it simply stops<br /> early (leaving OWN=0) and will retry where it left off when next called.<br /> <br /> This means descriptors have a three-stage lifecycle (terms my own):<br /> - `empty` (OWN=1, buffer valid)<br /> - `full` (OWN=0, buffer valid and populated)<br /> - `dirty` (OWN=0, buffer NULL)<br /> <br /> But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In<br /> the past (see &amp;#39;Fixes:&amp;#39;), there was a bug where the loop could cycle<br /> `cur_rx` all the way back to the first descriptor it dirtied, resulting<br /> in a NULL dereference when mistaken for `full`. The aforementioned<br /> commit resolved that *specific* failure by capping the loop&amp;#39;s iteration<br /> limit at `dma_rx_size - 1`, but this is only a partial fix: if the<br /> previous stmmac_rx_refill() didn&amp;#39;t complete, then there are leftover<br /> `dirty` descriptors that the loop might encounter without needing to<br /> cycle fully around. The current code therefore panics (see &amp;#39;Closes:&amp;#39;)<br /> when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to<br /> catch up to `dirty_rx`.<br /> <br /> Fix this by explicitly checking, before advancing `cur_rx`, if the next<br /> entry is dirty; exit the loop if so. This prevents processing of the<br /> final, used descriptor until stmmac_rx_refill() succeeds, but<br /> fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix<br /> intended: so remove the clamp as well. Since stmmac_rx_zc() is a<br /> copy-paste-and-tweak of stmmac_rx() and the code structure is identical,<br /> any fix to stmmac_rx() will also need a corresponding fix for<br /> stmmac_rx_zc(). Therefore, apply the same check there.<br /> <br /> In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the<br /> MAC sets OWN=0 on the final descriptor, it will be unable to send any<br /> further DMA-complete IRQs until it&amp;#39;s given more `empty` descriptors.<br /> Currently, the driver simply *hopes* that the next stmmac_rx_refill()<br /> succeeds, risking an indefinite stall of the receive process if not. But<br /> this is not a regression, so it can be addressed in a future change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_conn: fix potential UAF in create_big_sync<br /> <br /> Add hci_conn_valid() check in create_big_sync() to detect stale<br /> connections before proceeding with BIG creation. Handle the<br /> resulting -ECANCELED in create_big_complete() and re-validate the<br /> connection under hci_dev_lock() before dereferencing, matching the<br /> pattern used by create_le_conn_complete() and create_pa_complete().<br /> <br /> Keep the hci_conn object alive across the async boundary by taking<br /> a reference via hci_conn_get() when queueing create_big_sync(), and<br /> dropping it in the completion callback. The refcount and the lock<br /> are complementary: the refcount keeps the object allocated, while<br /> hci_dev_lock() serializes hci_conn_hash_del()&amp;#39;s list_del_rcu() on<br /> hdev-&gt;conn_hash, as required by hci_conn_del().<br /> <br /> hci_conn_put() is called outside hci_dev_unlock() so the final put<br /> (which resolves to kfree() via bt_link_release) does not run under<br /> hdev-&gt;lock, though the release path would be safe either way.<br /> <br /> Without this, create_big_complete() would unconditionally<br /> dereference the conn pointer on error, causing a use-after-free<br /> via hci_connect_cfm() and hci_conn_del().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix unlocked call to hns_roce_qp_remove()<br /> <br /> Sashiko points out that hns_roce_qp_remove() requires the caller to hold<br /> locks. The error flow in hns_roce_create_qp_common() doesn&amp;#39;t hold those<br /> locks for the error unwind so it risks corrupting memory.<br /> <br /> Grab the same locks the other two callers use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Fix shadow paging use-after-free due to unexpected GFN<br /> <br /> The shadow MMU computes GFNs for direct shadow pages using sp-&gt;gfn plus<br /> the SPTE index. This assumption breaks for shadow paging if the guest<br /> page tables are modified between VM entries (similar to commit<br /> aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even<br /> when creating an MMIO SPTE", 2026-03-27). The flow is as follows:<br /> <br /> - a PDE is installed for a 2MB mapping, and a page in that area is<br /> accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages;<br /> the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because<br /> the guest&amp;#39;s mapping is a huge page (and thus contiguous).<br /> <br /> - the PDE mapping is changed from outside the guest.<br /> <br /> - the guest accesses another page in the same 2MB area. KVM installs<br /> a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN<br /> (i.e. based on the new mapping, as changed in the previous step) but<br /> that GFN is outside of the [sp-&gt;gfn, sp-&gt;gfn + 511] range; therefore<br /> the rmap entry cannot be found and removed when the kvm_mmu_page<br /> is zapped.<br /> <br /> - the memslot that covers the first 2MB mapping is deleted, and the<br /> kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove()<br /> only looks at the [sp-&gt;gfn, sp-&gt;gfn + 511] range established in step 1,<br /> and fails to find the rmap entry that was recorded by step 3.<br /> <br /> - any operation that causes an rmap walk for the same page accessed<br /> by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page.<br /> This includes dirty logging or MMU notifier invalidations (e.g., from<br /> MADV_DONTNEED).<br /> <br /> The underlying issue is that KVM&amp;#39;s walking of shadow PTEs assumes that<br /> if a SPTE is present when KVM wants to install a non-leaf SPTE, then the<br /> existing kvm_mmu_page must be for the correct gfn. Because the only way<br /> for the gfn to be wrong is if KVM messed up and failed to zap a SPTE...<br /> which shouldn&amp;#39;t happen, but *actually* only happens in response to a<br /> guest write.<br /> <br /> That bug dates back literally forever, as even the first version of KVM<br /> assumes that the GFN matches and walks into the "wrong" shadow page.<br /> However, that was only an imprecision until 2032a93d66fa ("KVM: MMU:<br /> Don&amp;#39;t allocate gfns page for direct mmu pages") came along.<br /> <br /> Fix it by checking for a target gfn mismatch and zapping the existing<br /> SPTE. That way the old SP and rmap entries are gone, KVM installs<br /> the rmap in the right location, and everyone is happy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads<br /> <br /> atomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c<br /> unconditionally dereferences 8 bytes at payload_addr(pkt):<br /> <br /> value = *(u64 *)payload_addr(pkt);<br /> <br /> check_rkey() previously accepted an ATOMIC_WRITE request with pktlen ==<br /> resid == 0 because the length validation only compared pktlen against<br /> resid. A remote initiator that sets the RETH length to 0 therefore reaches<br /> atomic_write_reply() with a zero-byte logical payload, and the responder<br /> reads sizeof(u64) bytes from past the logical end of the packet into<br /> skb-&gt;head tailroom, then writes those 8 bytes into the attacker&amp;#39;s MR via<br /> rxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel<br /> tailroom per probe (the other 4 bytes are the packet&amp;#39;s own trailing ICRC).<br /> <br /> IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is<br /> protocol-invalid. Hoist a strict length check into check_rkey() so the<br /> responder never reaches the unchecked dereference, and keep the existing<br /> WRITE-family length logic for the normal RDMA WRITE path.<br /> <br /> Reproduced on mainline with an unmodified rxe driver: a sustained<br /> zero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer<br /> bytes into the attacker&amp;#39;s MR, including recognisable kernel strings and<br /> partial kernel-direct-map pointer words. With this patch applied the<br /> responder rejects the PDU and the MR stays all-zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: add pgmap check to biovec_phys_mergeable<br /> <br /> biovec_phys_mergeable() is used by the request merge, DMA mapping,<br /> and integrity merge paths to decide if two physically contiguous<br /> bvec segments can be coalesced into one. It currently has no check<br /> for whether the segments belong to different dev_pagemaps.<br /> <br /> When zone device memory is registered in multiple chunks, each chunk<br /> gets its own dev_pagemap. A single bio can legitimately contain<br /> bvecs from different pgmaps -- iov_iter_extract_bvecs() breaks at<br /> pgmap boundaries but the outer loop in bio_iov_iter_get_pages()<br /> continues filling the same bio. If such bvecs are physically<br /> contiguous, biovec_phys_mergeable() will coalesce them, making it<br /> impossible to recover the correct pgmap for the merged segment<br /> via page_pgmap().<br /> <br /> Add a zone_device_pages_have_same_pgmap() check to prevent merging<br /> bvec segments that span different pgmaps.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: use sk blob accessor in socket permission helpers<br /> <br /> SELinux socket state lives in the composite LSM socket blob.<br /> <br /> sock_has_perm() and nlmsg_sock_has_extended_perms() currently<br /> dereference sk-&gt;sk_security directly, which assumes the SELinux socket<br /> blob is at offset zero.<br /> <br /> In stacked configurations that assumption does not hold. If another LSM<br /> allocates socket blob storage before SELinux, these helpers may read the<br /> wrong blob and feed invalid SID and class values into AVC checks.<br /> <br /> Use selinux_sock() instead of accessing sk-&gt;sk_security directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eventfs: Hold eventfs_mutex and SRCU when remount walks events<br /> <br /> Commit 340f0c7067a9 ("eventfs: Update all the eventfs_inodes from the<br /> events descriptor") had eventfs_set_attrs() recurse through ei-&gt;children<br /> on remount. The walk only holds the rcu_read_lock() taken by<br /> tracefs_apply_options() over tracefs_inodes, which is wrong:<br /> <br /> - list_for_each_entry over ei-&gt;children races with the list_del_rcu()<br /> in eventfs_remove_rec() -- LIST_POISON1 deref, same shape as<br /> d2603279c7d6.<br /> - eventfs_inodes are freed via call_srcu(&amp;eventfs_srcu, ...).<br /> rcu_read_lock() does not extend an SRCU grace period, so ti-&gt;private<br /> can be reclaimed under the walk.<br /> - The writes to ei-&gt;attr race with eventfs_set_attr(), which holds<br /> eventfs_mutex.<br /> <br /> Reproducer:<br /> <br /> while :; do mount -o remount,uid=$((RANDOM%1000)) /sys/kernel/tracing; done &amp;<br /> while :; do<br /> echo "p:kp submit_bio" &gt; /sys/kernel/tracing/kprobe_events<br /> echo &gt; /sys/kernel/tracing/kprobe_events<br /> done<br /> <br /> Wrap the events portion of tracefs_apply_options() in<br /> eventfs_remount_lock()/_unlock() that take eventfs_mutex and<br /> srcu_read_lock(&amp;eventfs_srcu). eventfs_set_attrs() doesn&amp;#39;t sleep so the<br /> nested rcu_read_lock() is fine; lockdep_assert_held() pins the contract.<br /> <br /> Comment in tracefs_drop_inode() said "RCU cycle" -- it is SRCU.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Limit NVMe request size to 2 MiB<br /> <br /> The HBA firmware reports NVMe MDTS values based on the underlying drive<br /> capability. However, because the driver allocates a fixed 4K buffer for<br /> the PRP list, accommodating at most 512 entries, the driver supports a<br /> maximum I/O transfer size of 2 MiB.<br /> <br /> Limit max_hw_sectors to the smaller of the reported MDTS and the 2 MiB<br /> driver limit to prevent issuing oversized I/O that may lead to a kernel<br /> oops.

Relative Path Traversal vulnerability in Apache Ignite REST API.<br /> <br /> Authenticated REST API users can read any file on the server with "cmd=log" command and a log path crafted in a certain way.<br /> This issue affects Apache Ignite: from 2.0.0 through 2.17.0.<br /> <br /> Users are recommended to upgrade to version 2.18.0, which fixes the issue.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.9 before 18.10.7, 18.11 before 18.11.4, and 19.0 before 19.0.1 that under certain conditions could have allowed a blocked Project Access Token to continue accessing private resources due to incorrect authorization enforcement.