Vulnerabilities

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.

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().

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.

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().

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.

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.

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.

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.

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.

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.

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_log: validate MAC header was set before dumping it<br /> <br /> The fallback path of dump_mac_header() guards the MAC header access<br /> only with "skb-&gt;mac_header != skb-&gt;network_header", without checking<br /> skb_mac_header_was_set(). When the MAC header is unset, mac_header is<br /> 0xffff, so the test passes and skb_mac_header(skb) returns<br /> skb-&gt;head + 0xffff, ~64 KiB past the buffer; the loop then reads<br /> dev-&gt;hard_header_len bytes out of bounds into the kernel log.<br /> <br /> This is reachable via the netdev logger: nf_log_unknown_packet() calls<br /> dump_mac_header() unconditionally, and an skb sent through AF_PACKET<br /> with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still<br /> unset (__dev_queue_xmit(), which would reset it, is bypassed).<br /> <br /> Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already<br /> uses, and replace the open-coded MAC header length test with<br /> skb_mac_header_len(). Only skbs with an unset MAC header are affected;<br /> valid ones are dumped as before.<br /> <br /> BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831)<br /> Read of size 1 at addr ffff88800ea49d3f by task exploit/148<br /> Call Trace:<br /> kasan_report (mm/kasan/report.c:595)<br /> dump_mac_header (net/netfilter/nf_log_syslog.c:831)<br /> nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963)<br /> nf_log_packet (net/netfilter/nf_log.c:260)<br /> nft_log_eval (net/netfilter/nft_log.c:60)<br /> nft_do_chain (net/netfilter/nf_tables_core.c:285)<br /> nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307)<br /> nf_hook_slow (net/netfilter/core.c:619)<br /> nf_hook_direct_egress (net/packet/af_packet.c:257)<br /> packet_xmit (net/packet/af_packet.c:280)<br /> packet_sendmsg (net/packet/af_packet.c:3114)<br /> __sys_sendto (net/socket.c:2265)