Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Fix potential out-of-bounds access in __ceph_x_decrypt()<br /> <br /> In __ceph_x_decrypt(), a part of the buffer p is interpreted as a<br /> ceph_x_encrypt_header, and the magic field of this struct is accessed.<br /> This happens without any guarantee that the buffer is large enough to<br /> hold this struct. The function parameter ciphertext_len represents the<br /> length of the ciphertext to decrypt and is guaranteed to be at most the<br /> remaining size of the allocated buffer p. However, this value is not<br /> necessarily greater than sizeof(ceph_x_encrypt_header). E.g., a message<br /> frame of type FRAME_TAG_AUTH_REPLY_MORE, that is just as long to hold<br /> the ciphertext at its end with a ciphertext_len of 8 or less, can<br /> trigger an out-of-bounds memory access when accessing hdr-&gt;magic.<br /> <br /> This patch fixes the issue by adding a check to ensure that the<br /> decrypted plaintext in the buffer is large enough to represent at least<br /> the ceph_x_encrypt_header.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: handle rbtree insertion error in decode_choose_args()<br /> <br /> A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself<br /> contains a CRUSH map. The received CRUSH map may optionally contain<br /> choose_args that get decoded in decode_choose_args(). In this function,<br /> num_choose_arg_maps is read from the message, and a corresponding number<br /> of crush_choose_arg_maps gets decoded afterwards. Each<br /> crush_choose_arg_map has a choose_args_index, which serves as the key<br /> when inserting it into the choose_args rbtree of the decoded crush_map.<br /> If a (potentially corrupted) message contains two crush_choose_arg_maps<br /> with the same index, the assertion in insert_choose_arg_map() triggers a<br /> kernel BUG when trying to insert the second crush_choose_arg_map.<br /> <br /> This patch fixes the issue by switching to the non-asserting rbtree<br /> insertion function and rejecting the message if the insertion fails.<br /> <br /> [ idryomov: changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix oops due to out of scope access<br /> <br /> Below oops triggers when kill QEMU process:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI<br /> Call Trace:<br /> <br /> do_raw_spin_lock+0xaa/0xc0<br /> _raw_spin_lock_irqsave+0x21/0x40<br /> domain_remove_dev_pasid+0x52/0x160<br /> intel_nested_set_dev_pasid+0x1b9/0x1e0<br /> __iommu_set_group_pasid+0x56/0x120<br /> pci_dev_reset_iommu_done+0xe3/0x180<br /> pcie_flr+0x65/0x160<br /> __pci_reset_function_locked+0x5b/0x120<br /> vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core]<br /> vfio_df_close+0x4f/0xa0<br /> vfio_df_unbind_iommufd+0x2d/0x60<br /> vfio_device_fops_release+0x3e/0x40<br /> __fput+0xe5/0x2c0<br /> task_work_run+0x58/0xa0<br /> do_exit+0x2c8/0x600<br /> do_group_exit+0x2f/0xa0<br /> get_signal+0x863/0x8c0<br /> arch_do_signal_or_restart+0x24/0x100<br /> exit_to_user_mode_loop+0x87/0x380<br /> do_syscall_64+0x2ff/0x11e0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The global static blocked domain is a dummy domain without corresponding<br /> dmar_domain structure, accessing beyond iommu_domain structure triggers<br /> oops easily. Fix it by return early in domain_remove_dev_pasid() like<br /> identity domain.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure<br /> <br /> Apply the same fix as b2ed01e7ad ("drm/ttm: Fix ttm_bo_swapout()<br /> infinite LRU walk on swapout failure") to the ttm_bo_shrink() path.<br /> <br /> Move del_bulk_move from before the backup to after success only,<br /> using ttm_resource_del_bulk_move_unevictable() since the resource<br /> is now unevictable once fully backed up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/dma-buf: fix UAF with retry loop<br /> <br /> Retry doesn&amp;#39;t work here, since bo will be freed on error, leading to<br /> UAF. However, now that we do the alloc &amp; init before the attach, we can<br /> now combine this as one unit and have the init do the alloc for us. This<br /> should make the retry safe.<br /> <br /> Reported by Sashiko.<br /> <br /> v2: Fix up the error unwind (CI)<br /> <br /> (cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl<br /> <br /> While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong<br /> timeout value` warning was observed, accompanied by SMBus controller<br /> state machine corruption.<br /> <br /> The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of<br /> 10 ms. The user argument is checked against INT_MAX, but it is<br /> subsequently multiplied by 10 before being passed to msecs_to_jiffies().<br /> <br /> A malicious user can pass a large value (e.g., 429496729) that passes<br /> the `arg &gt; INT_MAX` check but overflows when multiplied by 10. This<br /> results in a truncated 32-bit unsigned value that bypasses the<br /> internal `(int)m adapter-&gt;timeout`<br /> (a signed 32-bit int), which is reinterpreted as a negative number.<br /> When passed to wait_for_completion_timeout(), this negative value<br /> undergoes sign extension to a 64-bit unsigned long, triggering the<br /> `schedule_timeout` warning and causing premature returns. This leaves<br /> the SMBus state machine in an unrecoverable state, constituting a<br /> local Denial of Service (DoS).<br /> <br /> Fix this by bounding the user argument to `INT_MAX / 10`.<br /> <br /> [wsa: move the comment as well]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove<br /> <br /> In qrtr_port_remove(), the socket reference count is decremented via<br /> __sock_put() before the port is removed from the qrtr_ports XArray and<br /> before the RCU grace period elapses.<br /> <br /> This breaks the fundamental RCU update paradigm. It exposes a race<br /> window where a concurrent RCU reader (such as qrtr_reset_ports() or<br /> qrtr_port_lookup()) can obtain a pointer to the socket from the XArray,<br /> and attempt to call sock_hold() on a socket whose reference count has<br /> already dropped to zero.<br /> <br /> This exact race condition was hit during syzkaller fuzzing, leading to<br /> the following refcount saturation warning and a potential Use-After-Free:<br /> <br /> refcount_t: saturated; leaking memory.<br /> WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0<br /> Modules linked in: qrtr(+) bochs drm_shmem_helper ...<br /> Call Trace:<br /> <br /> qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr]<br /> __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr]<br /> qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr]<br /> kernel_bind+0xe4/0x120 net/socket.c:3592<br /> qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr]<br /> qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr]<br /> do_one_initcall+0xf5/0x5e0 init/main.c:1283<br /> ...<br /> <br /> <br /> Fix this by deferring the reference count decrement until after the<br /> xa_erase() and the synchronize_rcu() complete.<br /> <br /> (Note: The v1 of this patch incorrectly replaced __sock_put() with<br /> sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove()<br /> still hold a reference to the socket, so freeing the socket memory here<br /> would lead to a subsequent UAF in the caller. Thus, the __sock_put() is<br /> kept, but only repositioned to close the RCU race.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling<br /> <br /> A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in<br /> send_sigio() and send_sigurg() when a process group receives a signal.<br /> <br /> When FASYNC is configured for a process group (PIDTYPE_PGID), both<br /> functions use read_lock(&amp;tasklist_lock) to traverse the task list.<br /> However, they are frequently called from softirq context:<br /> - send_sigio() via input_inject_event -&gt; kill_fasync<br /> - send_sigurg() via tcp_check_urg -&gt; sk_send_sigurg (NET_RX_SOFTIRQ)<br /> <br /> The deadlock is caused by the rwlock writer fairness mechanism:<br /> 1. CPU 0 (process context) holds read_lock(&amp;tasklist_lock) in do_wait().<br /> 2. CPU 1 (process context) attempts write_lock(&amp;tasklist_lock) in<br /> fork() or exit() and spins, which blocks all new readers.<br /> 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).<br /> 4. The softirq calls send_sigurg() and attempts to acquire<br /> read_lock(&amp;tasklist_lock), deadlocking because CPU 1 is waiting.<br /> <br /> Since PID hashing and do_each_pid_task() traversals are already<br /> RCU-protected, the read_lock on tasklist_lock is no longer strictly<br /> required for safe traversal. Fix this by replacing tasklist_lock with<br /> rcu_read_lock(), aligning the process group signaling path with the<br /> single-PID path. This also mitigates a potential remote denial of<br /> service vector via TCP URG packets.<br /> <br /> Lockdep splat:<br /> =====================================================<br /> WARNING: SOFTIRQ-safe -&gt; SOFTIRQ-unsafe lock order detected<br /> [...]<br /> Chain exists of:<br /> &amp;dev-&gt;event_lock --&gt; &amp;f_owner-&gt;lock --&gt; tasklist_lock<br /> <br /> Possible interrupt unsafe locking scenario:<br /> CPU0 CPU1<br /> ---- ----<br /> lock(tasklist_lock);<br /> local_irq_disable();<br /> lock(&amp;dev-&gt;event_lock);<br /> lock(&amp;f_owner-&gt;lock);<br /> <br /> lock(&amp;dev-&gt;event_lock);<br /> <br /> *** DEADLOCK ***

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "wireguard: device: enable threaded NAPI"<br /> <br /> This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is<br /> commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream.<br /> <br /> We have had three independent production user reports in combination<br /> with Cilium utilizing WireGuard as encryption underneath that k8s Pod<br /> E/W traffic to certain peer nodes fully stalled. The situation appears<br /> as follows:<br /> <br /> - Occurs very rarely but at random times under heavy networking load.<br /> - Once the issue triggers the decryption side stops working completely<br /> for that WireGuard peer, other peers keep working fine. The stall<br /> happens also for newly initiated connections towards that particular<br /> WireGuard peer.<br /> - Only the decryption side is affected, never the encryption side.<br /> - Once it triggers, it never recovers and remains in this state,<br /> the CPU/mem on that node looks normal, no leak, busy loop or crash.<br /> - bpftrace on the affected system shows that wg_prev_queue_enqueue<br /> fails, thus the MAX_QUEUED_PACKETS (1024 skbs!) for the peer&amp;#39;s<br /> rx_queue is reached.<br /> - Also, bpftrace shows that wg_packet_rx_poll for that peer is never<br /> called again after reaching this state for that peer. For other<br /> peers wg_packet_rx_poll does get called normally.<br /> - Commit db9ae3b ("wireguard: device: enable threaded NAPI")<br /> switched WireGuard to threaded NAPI by default. The default has<br /> not been changed for triggering the issue, neither did CPU<br /> hotplugging occur (i.e. 5bd8de2 ("wireguard: queueing: always<br /> return valid online CPU in wg_cpumask_choose_online()")).<br /> - The issue has been observed with stable kernels of v5.15 as well as<br /> v6.1. It was reported to us that v5.10 stable is working fine, and<br /> no report on v6.6 stable either (somewhat related discussion in [0]<br /> though).<br /> - In the WireGuard driver the only material difference between v5.10<br /> stable and v5.15 stable is the switch to threaded NAPI by default.<br /> <br /> [0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/<br /> <br /> Breakdown of the problem:<br /> <br /> 1) skbs arriving for decryption are enqueued to the peer-&gt;rx_queue in<br /> wg_packet_consume_data via wg_queue_enqueue_per_device_and_peer.<br /> 2) The latter only moves the skb into the MPSC peer queue if it does<br /> not surpass MAX_QUEUED_PACKETS (1024) which is kept track in an<br /> atomic counter via wg_prev_queue_enqueue.<br /> 3) In case enqueueing was successful, the skb is also queued up<br /> in the device queue, round-robin picks a next online CPU, and<br /> schedules the decryption worker.<br /> 4) The wg_packet_decrypt_worker, once scheduled, picks these up<br /> from the queue, decrypts the packets and once done calls into<br /> wg_queue_enqueue_per_peer_rx.<br /> 5) The latter updates the state to PACKET_STATE_CRYPTED on success<br /> and calls napi_schedule on the per peer-&gt;napi instance.<br /> 6) NAPI then polls via wg_packet_rx_poll. wg_prev_queue_peek checks<br /> on the peer-&gt;rx_queue. It will wg_prev_queue_dequeue if the<br /> queue-&gt;peeked skb was not cached yet, or just return the latter<br /> otherwise. (wg_prev_queue_drop_peeked later clears the cache.)<br /> 7) From an ordering perspective, the peer-&gt;rx_queue has skbs in order<br /> while the device queue with the per-CPU worker threads from a<br /> global ordering PoV can finish the decryption and signal the skb<br /> PACKET_STATE_CRYPTED out of order.<br /> 8) A situation can be observed that the first packet coming in will<br /> be stuck waiting for the decryption worker to be scheduled for<br /> a longer time when the system is under pressure.<br /> 9) While this is the case, the other CPUs in the meantime finish<br /> decryption and call into napi_schedule.<br /> 10) Now in wg_packet_rx_poll it picks up the first in-order skb<br /> from the peer-&gt;rx_queue and sees that its state is still<br /> PACKET_STATE_UNCRYPTED. The NAPI poll routine then exits e<br /> ---truncated---

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Feast before 0.63.0 contains an unsafe deserialization vulnerability that allows unauthenticated or unauthorized attackers to achieve remote code execution by sending a crafted gRPC request to the registry server. The user_defined_function.body field of an OnDemandFeatureView spec is decoded from base64 and passed to dill.loads() before any authorization check is performed, enabling attackers to embed a malicious serialized Python object with an arbitrary __reduce__ method to execute OS commands as the feast service account.