Vulnerabilidades

*** Pendiente de traducción *** 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.)

*** Pendiente de traducción *** 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 ***

*** Pendiente de traducción *** 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---

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** Marlin Firmware through 2.1.2.7, fixed in commit 1f255d1, when built with MESH_BED_LEVELING enabled, contains an out-of-bounds write vulnerability in the M421 G-code handler that allows attackers to corrupt firmware memory by supplying out-of-range X and Y grid indices. Attackers can send a single crafted G-code command via USB serial, network interface, or malicious gcode file to write an attacker-controlled 32-bit float value past the z_values array bounds, corrupting adjacent firmware variables and causing denial of service or firmware state corruption.

*** Pendiente de traducción *** A Reflected Cross-Site Scripting (XSS) vulnerability exists in Frappe Framework version 17.0.0-dev due to improper neutralization of user-controlled input in the dashboard-view component.

*** Pendiente de traducción *** A Stored Cross-Site Scripting (XSS) vulnerability exists in Frappe Framework version 17.0.0-dev due to improper neutralization of user-controlled input in the Desk desktop icon renderer.

*** Pendiente de traducción *** A Stored Cross-Site Scripting (XSS) vulnerability exists in Frappe Framework version 17.0.0-dev due to improper neutralization of user-controlled input in the File View breadcrumb renderer.

*** Pendiente de traducción *** A Cross-Site Scripting (XSS) vulnerability exists in Frappe Framework version 17.0.0-dev due to improper neutralization of untrusted input in the Form Dashboard headline renderer.

*** Pendiente de traducción *** A Stored Cross-Site Scripting (XSS) vulnerability exists in Frappe Framework version 17.0.0-dev due to improper neutralization of user-controlled input in the MultiSelectDialog component.