Vulnerabilities

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)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tap: fix stack info leak in tap_ioctl() SIOCGIFHWADDR<br /> <br /> In the SIOCGIFHWADDR path, tap_ioctl() copies 16 bytes of an<br /> uninitialised on-stack struct sockaddr_storage to userspace via<br /> ifr_hwaddr, but netif_get_mac_address() only writes sa_family and<br /> dev-&gt;addr_len (6 for Ethernet) bytes, leaving sa_data[6..13] uninitialised.<br /> <br /> Those 8 trailing bytes leak kernel stack contents; SIOCGIFHWADDR on a<br /> macvtap chardev returns kernel .text and direct-map pointers, defeating<br /> KASLR.<br /> <br /> Initialise ss at declaration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: jitterentropy - replace long-held spinlock with mutex<br /> <br /> jent_kcapi_random() serializes the shared jitterentropy state, but it<br /> currently holds a spinlock across the jent_read_entropy() call. That<br /> path performs expensive jitter collection and SHA3 conditioning, so<br /> parallel readers can trigger stalls as contending waiters spin for<br /> the same lock.<br /> <br /> To prevent non-preemptible lock hold, replace rng-&gt;jent_lock with a<br /> mutex so contended readers sleep instead of spinning on a shared lock<br /> held across expensive entropy generation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: espintcp: do not reuse an in-progress partial send<br /> <br /> espintcp keeps a single in-flight transmit in ctx-&gt;partial.<br /> Before building a new sk_msg, espintcp_sendmsg() first tries to flush<br /> that state through espintcp_push_msgs().<br /> <br /> For blocking callers, espintcp_push_msgs() may return success even when<br /> the previous partial send is still pending. espintcp_sendmsg() would<br /> then reinitialize emsg-&gt;skmsg and reuse ctx-&gt;partial while the old<br /> transfer still owns that state.<br /> <br /> Do not rebuild the send message when ctx-&gt;partial is still in progress.<br /> If espintcp_push_msgs() returns with emsg-&gt;len still set, fail the new<br /> send instead of overwriting the live partial state.<br /> <br /> This is a memory-safety fix: reusing the live partial-send state can<br /> leave a stale offset attached to a new sk_msg and lead to an out-of-<br /> bounds read in the send path.<br /> <br /> tcp_sendmsg_locked() already handles waiting for send buffer memory, so<br /> the fix here is just to preserve espintcp&amp;#39;s one-message-at-a-time<br /> transmit state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/poll: fix signed comparison in io_poll_get_ownership()<br /> <br /> io_poll_get_ownership() uses a signed comparison to check whether<br /> poll_refs has reached the threshold for the slowpath:<br /> <br /> if (unlikely(atomic_read(&amp;req-&gt;poll_refs) &gt;= IO_POLL_REF_BIAS))<br /> <br /> atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG<br /> (BIT(31)) is set in poll_refs, the value becomes negative in<br /> signed arithmetic, so the &gt;= 128 comparison always evaluates to<br /> false and the slowpath is never taken.<br /> <br /> Fix this by casting the atomic_read() result to unsigned int<br /> before the comparison, so that the cancel flag is treated as a<br /> large positive value and correctly triggers the slowpath.