Vulnerabilidades

*** Pendiente de traducción *** The AdRotate Banner Manager plugin for WordPress is vulnerable to PHP Code Injection in all versions up to, and including, 5.17.7 via the 'banner' attribute of the adrotate shortcode. This is due to insufficient input validation and sanitization of the banner shortcode attribute before concatenation into a PHP code string wrapped in W3 Total Cache mfunc or Borlabs Cache fragment markers. This makes it possible for authenticated attackers, with Contributor-level access and above, to execute arbitrary PHP code on the server. This vulnerability requires W3 Total Cache or Borlabs Cache support to be enabled in AdRotate settings.

*** Pendiente de traducción *** Flowise through 2.2.7 contains a SQL injection vulnerability in the importChatflows API. Due to insufficient validation of the chatflow.id value, an authenticated user can supply a crafted JSON import file whose id field is concatenated unsanitized into a SQL IN clause, allowing arbitrary SQL to be executed, including blind and error-based extraction of data from the credential table.

*** Pendiente de traducción *** picklescan before 0.0.29 fails to detect malicious pickle files that exploit idlelib.debugobj.ObjectTreeItem.SetText function in reduce methods. Attackers can craft pickle files with embedded code that bypasses picklescan detection and executes arbitrary commands when pickle.load() is called.

*** Pendiente de traducción *** picklescan before 0.0.29 fails to detect malicious idlelib.calltip.Calltip.fetch_tip calls in pickle files, allowing remote code execution. Attackers can embed undetected payloads in pickle files that execute arbitrary code when loaded via pickle.load().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: skbuff: fix missing zerocopy reference in pskb_carve helpers<br /> <br /> pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy<br /> the old skb_shared_info header into a new buffer via memcpy(), which<br /> includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs.<br /> Neither function calls net_zcopy_get() for the new shinfo, creating an<br /> unaccounted holder: every skb_shared_info with destructor_arg set will<br /> call skb_zcopy_clear() once when freed, but the corresponding<br /> net_zcopy_get() was never called for the new copy. Repeated calls<br /> drive uarg-&gt;refcnt to zero prematurely, freeing ubuf_info_msgzc while<br /> TX skbs still hold live destructor_arg pointers.<br /> <br /> KASAN reports use-after-free on a freed ubuf_info_msgzc:<br /> <br /> BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810<br /> Read of size 8 at addr ffff88801574d3e8 by task poc/220<br /> <br /> Call Trace:<br /> skb_release_data+0x77b/0x810<br /> kfree_skb_list_reason+0x13e/0x610<br /> skb_release_data+0x4cd/0x810<br /> sk_skb_reason_drop+0xf3/0x340<br /> skb_queue_purge_reason+0x282/0x440<br /> rds_tcp_inc_free+0x1e/0x30<br /> rds_recvmsg+0x354/0x1780<br /> __sys_recvmsg+0xdf/0x180<br /> <br /> Allocated by task 219:<br /> msg_zerocopy_realloc+0x157/0x7b0<br /> tcp_sendmsg_locked+0x2892/0x3ba0<br /> <br /> Freed by task 219:<br /> ip_recv_error+0x74a/0xb10<br /> tcp_recvmsg+0x475/0x530<br /> <br /> The skb consuming the late access still referenced the same uarg via<br /> shinfo-&gt;destructor_arg copied by pskb_carve_inside_nonlinear() without<br /> a refcount bump. This has been verified to be reliably exploitable: a<br /> working proof-of-concept achieves full root privilege escalation from<br /> an unprivileged local user on a default kernel configuration.<br /> <br /> The fix follows the pattern of pskb_expand_head() which has the same<br /> memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get()<br /> is placed after skb_orphan_frags() succeeds, so the orphan error path<br /> needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is<br /> placed after all failure points and just before skb_release_data(), so<br /> no error path needs cleanup at all -- matching pskb_expand_head() more<br /> closely and avoiding the need for a balancing net_zcopy_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE<br /> <br /> FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file&amp;#39;s sparse<br /> attribute and saves it through xattr without any permission checks.<br /> <br /> This exposes two issues:<br /> <br /> 1) A client on a read-only share can change the sparse attribute<br /> on files it opened, even though the share is read-only.<br /> Other FSCTL write operations already check<br /> test_tree_conn_flag(work-&gt;tcon, KSMBD_TREE_CONN_FLAG_WRITABLE),<br /> but FSCTL_SET_SPARSE does not.<br /> <br /> 2) Even on writable shares, clients without FILE_WRITE_DATA or<br /> FILE_WRITE_ATTRIBUTES access should not modify the sparse<br /> attribute. Similar handle-level checks exist in other functions<br /> but are missing here.<br /> <br /> Add both share-level writable check and per-handle access check.<br /> Use goto out on error to avoid leaking file references.

*** Pendiente de traducción *** Improper Neutralization of Special Elements used in an SQL Command (&amp;#39;SQL Injection&amp;#39;) vulnerability in FunnelKit Funnel Builder by FunnelKit allows Blind SQL Injection.<br /> <br /> This issue affects Funnel Builder by FunnelKit: from n/a through 3.15.0.5.

*** Pendiente de traducción *** The Ultimate Member plugin for WordPress is vulnerable to Account Takeover via Password Reset Link Disclosure in all versions up to and including 2.11.4. This is due to a chain of three logic bugs: (1) an MD5 hash fallback in get_directory_by_hash() that allows any post to be used as a member directory by computing SUBSTRING(MD5(post_id), 11, 5), (2) a strstr() parsing logic flaw in post_data() that allows bypassing WordPress&amp;#39;s protected meta key restrictions by placing &amp;#39;_um_&amp;#39; anywhere in the meta key name rather than at the start, and (3) missing field name validation in build_user_card_data() that allows arbitrary field names including &amp;#39;password_reset_link&amp;#39; to be passed to um_filtered_value(). This makes it possible for authenticated attackers with Contributor-level access and above to create a malicious post via XMLRPC with crafted meta fields, use the MD5 fallback to point the member directory AJAX handler to their post, inject &amp;#39;password_reset_link&amp;#39; into the tagline_fields configuration, and leak live password reset URLs for all users in the member directory response, including administrators.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: avoid NULL deref of conn-&gt;lnk in smc_msg_event tracepoint<br /> <br /> The smc_msg_event tracepoint class, shared by smc_tx_sendmsg and<br /> smc_rx_recvmsg, unconditionally dereferences smc-&gt;conn.lnk:<br /> <br /> __string(name, smc-&gt;conn.lnk-&gt;ibname)<br /> <br /> conn-&gt;lnk is only set for SMC-R; for SMC-D it is NULL. Other code on<br /> these paths already handles this (e.g. !conn-&gt;lnk in<br /> SMC_STAT_RMB_TX_SIZE_SMALL()). With the tracepoint enabled, the first<br /> sendmsg()/recvmsg() on an SMC-D socket crashes:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> KASAN: null-ptr-deref in range [...]<br /> RIP: 0010:strlen+0x1e/0xa0<br /> Call Trace:<br /> trace_event_raw_event_smc_msg_event (net/smc/smc_tracepoint.h:44)<br /> smc_rx_recvmsg (net/smc/smc_rx.c:515)<br /> smc_recvmsg (net/smc/af_smc.c:2859)<br /> __sys_recvfrom (net/socket.c:2315)<br /> __x64_sys_recvfrom (net/socket.c:2326)<br /> do_syscall_64<br /> <br /> The faulting address 0x3e0 is offsetof(struct smc_link, ibname),<br /> confirming the NULL -&gt;lnk deref. Enabling the tracepoint requires<br /> root, but the trigger itself is unprivileged: socket(AF_SMC, ...) has<br /> no capability check, and SMC-D negotiation needs no admin step on<br /> s390 or on x86 with the loopback ISM device loaded.<br /> <br /> Log an empty device name for SMC-D instead of dereferencing NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tun: zero the whole vnet header in tun_put_user()<br /> <br /> tun_put_user() declares an on-stack struct virtio_net_hdr_v1_hash_tunnel<br /> without zeroing it. For a non-tunnel skb, virtio_net_hdr_tnl_from_skb()<br /> only initializes the first 10 bytes (sizeof(struct virtio_net_hdr)),<br /> leaving bytes 10..23 (num_buffers and the hash/tunnel fields) as stack<br /> garbage.<br /> <br /> An unprivileged user can set the vnet header size to 24 with<br /> TUNSETVNETHDRSZ, so __tun_vnet_hdr_put() copies all 24 bytes of the<br /> partially-initialized struct to userspace, leaking 14 bytes of kernel<br /> stack on every read of a non-tunnel packet.<br /> <br /> Fix it the same way tun_get_user() already does by zeroing the whole<br /> header right after declaration.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion<br /> <br /> rds_ib_xmit_atomic() always programs a masked atomic opcode<br /> (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD)<br /> for every RDS atomic cmsg. But the completion-side switch in<br /> rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked<br /> atomic completion falls through to default and returns rm == NULL while<br /> send-&gt;s_op is left set. rds_ib_send_cqe_handler() then dereferences the<br /> NULL rm via rm-&gt;m_final_op, oopsing in softirq context. An unprivileged<br /> AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection<br /> triggers it; on hardware that natively accepts masked atomics (mlx4,<br /> mlx5) no extra setup is needed.<br /> <br /> RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR!<br /> Oops: general protection fault [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197]<br /> RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282)<br /> Call Trace:<br /> <br /> rds_ib_send_cqe_handler (net/rds/ib_send.c:282)<br /> poll_scq (net/rds/ib_cm.c:274)<br /> rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294)<br /> tasklet_action_common (kernel/softirq.c:943)<br /> handle_softirqs (kernel/softirq.c:573)<br /> run_ksoftirqd (kernel/softirq.c:479)<br /> <br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> Handle the masked atomic opcodes in the same case as the non-masked<br /> ones: they map to the same struct rds_message.atomic union member, so<br /> the existing container_of()/rds_ib_send_unmap_atomic() body is correct<br /> for them.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix NULL pointer dereference in bpf_sk_storage_clone and diag paths<br /> <br /> bpf_selem_unlink_nofail() sets SDATA(selem)-&gt;smap to NULL before<br /> removing the selem from the storage hlist. A concurrent RCU reader in<br /> bpf_sk_storage_clone() can observe the selem still on the list with<br /> smap already NULL, causing a NULL pointer dereference.<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc000000000a:<br /> KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]<br /> RIP: 0010:bpf_sk_storage_clone+0x1cd/0xaa0 net/core/bpf_sk_storage.c:174<br /> Call Trace:<br /> <br /> sk_clone+0xfed/0x1980 net/core/sock.c:2591<br /> inet_csk_clone_lock+0x30/0x760 net/ipv4/inet_connection_sock.c:1222<br /> tcp_create_openreq_child+0x35/0x2680 net/ipv4/tcp_minisocks.c:571<br /> tcp_v4_syn_recv_sock+0x123/0xf90 net/ipv4/tcp_ipv4.c:1729<br /> tcp_check_req+0x8e1/0x2580 include/net/tcp.h:855<br /> tcp_v4_rcv+0x1845/0x3b80 net/ipv4/tcp_ipv4.c:2347<br /> <br /> Add a NULL check for smap in bpf_sk_storage_clone().<br /> <br /> bpf_sk_storage_diag_put_all() has the same issue. Add a NULL check<br /> and pass the validated smap directly to diag_get(), which is refactored<br /> to take smap as a parameter instead of reading it internally.<br /> <br /> bpf_sk_storage_diag_put() uses diag-&gt;maps[i] which is always valid<br /> under its refcount, so diag-&gt;maps[i] is passed directly to diag_get().