The Royal Elementor Addons WordPress plugin before 1.7.1070 does not validate submitted form field values before substituting them into the recipient addresses of its form notification emails, allowing unauthenticated attackers to replace the recipient list and relay attacker-composed email from the site's own domain when a recipient field is configured to echo a submitted value.
The BitPay Gateway for WooCommerce WordPress plugin through 4.1.3 does not bind the payment provider's transaction confirmation to the order it completes, nor verify the confirmed amount, allowing an unauthenticated attacker who holds a single genuine low-value transaction to mark arbitrary higher-value orders as paid.
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: Don't reset VMBus connection state on error/exit paths
In two places, current code forces vmbus_connection.conn_state to
DISCONNECTED prior to calling vmbus_disconnect(). But vmbus_disconnect()
calls vmbus_initiate_unload(), which unloads the VMBus connection
only if the conn_state is CONNECTED. Consequently, the connection
remains and the Hyper-V host might continue to send messages or post
VMBus interrupts.
The problem was introduced in commit 74347a99e73ae ("x86/Hyper-V:
Unload vmbus channel in hv panic callback"), in that
vmbus_initiate_unload() started checking the current connection
state before doing the unload. This commit removed some occurrences
where conn_state was forced to DISCONNECTED, but these two remained,
apparently due to an oversight at the time.
Fix this by not forcing conn_state to DISCONNECTED during VMBus exit,
or if a failure occurs when establishing the connection in the first
place. Whatever value conn_state has at the time is then read by
vmbus_initiate_unload() to determine if there is a connection to
be unloaded.
In the Linux kernel, the following vulnerability has been resolved:
vsock: treat TCP_CLOSING as once-established
Handle the TCP_ESTABLISHED -> TCP_CLOSING transition on OP_RST, which can
race with the connect loop. Immediately break and return 0 on
ESTABLISHED/CLOSING. The return value of connect() should reflect what
happened up to the point the connection was established or failed. Events
that occur afterwards must not affect it. E.g. even if OP_RW has already
set sk_err, connect() should still return 0, not ENOBUFS because of it.
Adapt the inaccurate comment above signal_pending().
Resetting a socket that is still present in connected_table can lead to
memory corruption. The reporter noted lost transports for in-flight skbs,
and I have reproduced crashes caused by re-insertion into connected_table.
list_add double add: new=, prev=, next=.
kernel BUG at lib/list_debug.c:35!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
Workqueue: vsock-loopback vsock_loopback_work
RIP: 0010:__list_add_valid_or_report+0x11f/0x130
Call Trace:
vsock_insert_connected.cold+0xe/0x13
virtio_transport_recv_pkt+0x10e9/0x1460
vsock_loopback_work+0x305/0x480
process_one_work+0xe4c/0x1560
worker_thread+0x4f1/0xd60
kthread+0x36e/0x470
ret_from_fork+0x47b/0x6b0
ret_from_fork_asm+0x1a/0x30
This fix is supplementary to commit 002541ef650b ("vsock: Ignore
signal/timeout on connect() if already established"). Details under Link.
In the Linux kernel, the following vulnerability has been resolved:
net/rds: don't let the rdma_cm destroy an id RDS still owns on route failure
rds_rdma_cm_event_handler_cmn() hands the return value of
rdma_resolve_route() straight back to the rdma_cm on
RDMA_CM_EVENT_ADDR_RESOLVED. A synchronous failure there - -ENOMEM
from the route work allocation, an SA query that cannot be set up, a
RoCE route with no usable device - makes addr_handler() destroy the
id the event was delivered on. That id is ic->i_cm_id, and nothing
clears the pointer: the connection sits in RDS_CONN_CONNECTING with a
freed id until its shutdown calls rdma_disconnect() and
rdma_destroy_id() on it.
The ROUTE_RESOLVED case already avoids this: rds_ib_cm_initiate_connect()
forces a zero return while ic->i_cm_id == cm_id, as the comment there
explains. Do the same here - drop the connection and return 0 - so
the id stays RDS's to destroy from the shutdown, and the reconnect
gets a fresh one.
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix race in discovery auth updates
Separate configfs opens can concurrently update the discovery AuthMethod
parameter. Both callers may free the same value in
iscsi_update_param_value(), causing a double-free.
Protect the lookup and replacement with the discovery TPG access lock,
as used by the other TPG configfs parameter updates.
In the Linux kernel, the following vulnerability has been resolved:
firewire: core: fix race condition in split transaction handling
For a split transaction, either fw_core_handle_response() or
split_transaction_timeout_callback() may manipulate the same transaction
entry in the pending transaction list. The return value of timer_delete()
is used to determine which function handles the entry. If the transaction
is a split transaction and timer_delete() returns zero, the timeout
callback may already be running. In this case, the response handler must
leave the entry in the list for the timeout callback to remove.
A previous code refactoring broke this behavior, introducing a race
condition in which both functions could process the same transaction.
This could lead to a use-after-free on the transaction initiator side.
Fix the regression by ensuring that the response handler does not process
the transaction when timer_delete() returns zero. The timeout callback is
responsible for removing the entry from the pending transaction list.
In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields
In check_synth_field(), when a synthetic event field is a stacktrace
(field->is_stack) and the histogram field is not a "long[" stacktrace
array, validation falls through to the generic size and signedness
comparison.
Because parse_synth_field() sets a stacktrace field's type to
"__data_loc unsigned long[]", its size is sizeof(u64) and
synth_field_signed() marks it as signed. Consequently, any 8-byte
signed scalar histogram field passes the fallback check, and its scalar
value is subsequently dereferenced as a kernel stacktrace pointer in
get_field_size() and trace_stack().
Furthermore, checking strstr(hist_field->type, "long[") is insufficient
because tracepoint fields defined with __bitmask() or __rel_bitmask()
also have type "__data_loc unsigned long[]" or "__rel_loc unsigned
long[]", whilst create_hist_field() treats them as 4-byte scalar values
without HIST_FIELD_FL_STACKTRACE.
Propagate HIST_FIELD_FL_STACKTRACE to variable references and field
variables (whilst excluding variable aliases from per-element
stacktrace capture), and reject any mismatch between
HIST_FIELD_FL_STACKTRACE and field->is_stack in check_synth_field().
In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsi: Reject a negative task index from parse_pdu_itt
A transport that implements parse_pdu_itt hands libiscsi an index taken
from the PDU, and both lookups bound it from above only:
if (i >= session->cmds_max)
i and cmds_max are both int, so a negative index passes and
session->cmds[i] is read from before the array.
be2iscsi produces one. beiscsi_parse_pdu() assigns the raw tag,
*index = (int)itt;
and beiscsi_complete_pdu() forwards an unsolicited NOP-In from the
hardware async ring without replacing its ITT, so the value is the
target's. It also reports the session's own age rather than the one in
the tag, which leaves the age comparison in iscsi_verify_itt() with
nothing to reject.
Bound the index from below in both lookups.
In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsi: Validate the ITT reflected in a Reject PDU
A Reject PDU carries a copy of the header it rejects, and
iscsi_handle_reject() takes the ITT out of that copy to find the task to
clean up:
memcpy(&rejected_pdu, data, sizeof(struct iscsi_hdr));
...
task = iscsi_itt_to_task(conn, rejected_pdu.itt);
That value is whatever the target put there. iscsi_itt_to_task() bounds
the index against cmds_max and checks nothing else, so any task in the
pool can be named, and iscsi_nop_out_rsp() then completes it.
An index that has never been used gives a NULL task->conn: the pool is
zeroed at session setup and conn is assigned only when a task is
allocated. If the task was used and returned, iscsi_complete_task() hits
its WARN_ON_ONCE(task->state == ISCSI_TASK_FREE) and the refcount
underflows. An in-flight SCSI command is completed as successful - a 1
MiB read returned 1048576 with none of its buffer written and no
warning.
Validate the reflected ITT the way iscsi_itt_to_ctask() validates a
command ITT, and require the task to be in flight and not a SCSI
command.
[ 6.248477] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI
[ 6.249357] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]
[ 6.249951] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy)
[ 6.250718] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 6.251616] RIP: 0010:iscsi_nop_out_rsp.constprop.0+0x46/0x160
[ 6.252043] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00
[ 6.252813] RSP: 0018:ffff88806c907b80 EFLAGS: 00010206
[ 6.253042] RAX: dffffc0000000000 RBX: ffff88800607e000 RCX: ffffffff8d571a25
[ 6.253345] RDX: 000000000000000c RSI: ffff88806c907c38 RDI: 0000000000000060
[ 6.253642] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff235a504
[ 6.253947] R10: 0000000000000003 R11: 7463656e6e6f6320 R12: 0000000000000000
[ 6.254251] R13: 0000000000000000 R14: ffff88806c907c38 R15: 0000000000000000
[ 6.254549] FS: 0000000000000000(0000) GS:ffff8880d95bc000(0000) knlGS:0000000000000000
[ 6.254887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6.255140] CR2: 00007fc393e8ffc0 CR3: 0000000005252006 CR4: 0000000000770ef0
[ 6.255439] PKRU: 55555554
[ 6.255564] Call Trace:
[ 6.255674] <IRQ>
[ 6.255768] __iscsi_complete_pdu+0x18bf/0x22a0
[ 6.256733] iscsi_complete_pdu+0x54/0xa0
[ 6.256905] iscsi_tcp_data_recv_done+0xf4/0x250
[ 6.257103] iscsi_tcp_recv_skb+0x31e/0xec0
[ 6.257680] iscsi_sw_tcp_recv+0x12f/0x390
[ 6.258061] __tcp_read_sock+0x1ab/0x810
[ 6.258853] iscsi_sw_tcp_data_ready+0x18b/0x510
[ 6.259808] tcp_data_queue+0x1f13/0x4cd0
[ 6.260567] tcp_rcv_established+0x8a5/0x3a00
[ 6.261931] tcp_v4_do_rcv+0x449/0x960
[ 6.262269] tcp_v4_rcv+0x2245/0x3bc0
In the Linux kernel, the following vulnerability has been resolved:
tracing: Keep the predicate limit separate from program capacity
predicate_parse() adds two to nr_preds to reserve the terminal TRUE
and FALSE entries. It also uses that increased value as the limit for
parsed predicates. If the initial count is smaller than the number
actually parsed, the program can fill the allocation and subsequent
accesses can go past its end.
Keep nr_preds as the predicate limit and use a separate value for the
allocation size. This leaves space for both terminal entries and a
zeroed entry when parsing stops at the limit.
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix data race and NULL deref on local->assoc_dev
local->assoc_dev is shared between the association path and the
association-response worker without common synchronization.
mac802154_perform_association() stores the coordinator pointer and waits
for a response. Its timeout and error paths clear the pointer and return
to mac802154_associate(), which may then free the coordinator object.
Meanwhile, mac802154_rx_mac_cmd_worker() may observe the associating bit
and enter mac802154_process_association_resp(), which dereferences
assoc_dev.
The worker's bit test and the handler's pointer dereference are not
atomic with respect to cleanup. Cleanup can clear assoc_dev between them,
causing a NULL dereference, or free the coordinator while the response
handler still uses the pointer.
The recorded result is exposed to the same window. assoc_status and
assoc_addr are written by the handler but read by the association path
while the associating bit is still set, so a second response for the same
request - a malicious one, for instance - can replace them between those
reads and leave the caller with an incoherent status and address pair.
The response handler only needs the coordinator extended address.
Replace assoc_dev with a cached address, removing the pointer lifetime
dependency. Protect the cached address and the associating bit with a
dedicated spinlock. A READ_ONCE()/WRITE_ONCE() pair would not guarantee
an atomic __le64 access on all 32-bit architectures.
wpan_dev->association_lock cannot be reused here: nl802154_associate()
holds it across rdev_associate(), hence for the whole of
mac802154_perform_association() including the wait for the response.
A response handler taking that lock would only get it once the
association has already given up.
Reset the completion, publish the cached address, and set the associating
bit while holding the lock. The response handler takes the lock, rechecks
the bit and the cached address, records the response, clears the bit, and
only then completes the waiter. Thus cleanup cannot pass the handler
between its state check and completion, and the cached 64-bit value
cannot tear.
The handler clears the bit before completing, not the woken waiter:
otherwise complete() is issued under the lock and a second (e.g.
malicious) response can reacquire it before the waiter and replace the
result. So a wait that returns success implies the bit is already clear,
and the success and negative-response paths return directly. The
transmit-error and timeout paths still clear it under assoc_lock, which
serializes any racing response against the cleanup while the call returns
the error it already selected. Both paths snapshot assoc_status and
assoc_addr under the same lock.
Both users run in process context, so a plain spinlock is sufficient.
The lock is not held while waiting for the completion.
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: fix the recvmsg window update
iucv_sock_recvmsg() sends the HiperSockets-only AF_IUCV_FLAG_WIN without
testing the transport, so on a classic z/VM socket iucv_send_ctrl() sizes
the skb through a NULL iucv->hs_dev. SO_MSGLIMIT accepts 1, so msglimit / 2
is zero and one recvmsg() on its own socket is enough for an unprivileged
process to take a spurious disconnect.
It also calls iucv_send_ctrl() under spin_lock_bh(&message_q.lock), which
allocates GFP_KERNEL inside a section the code treats as atomic. Sending
outside that lock lets two recvmsg() reach afiucv_hs_send() at once, where
msg_recv is sampled for the advertised window and subtracted after
dev_queue_xmit() -- and sendmsg reaches that counter under lock_sock()
while recvmsg holds no socket lock, so both can subtract the same value,
the counter goes negative and the credit reaches the peer twice.
Test the transport, claim the credit with atomic_xchg() after the last
error exit and hand it back if the transmit fails, and send once the lock
is dropped.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION
smb2_get_info_filesystem() reports 56 bytes for FS_POSIX_INFORMATION,
that is the whole of FILE_SYSTEM_POSIX_INFO, but never assigns
FileSysIdentifier. Those eight bytes go to the client as they are found
in the response buffer.
The buffer is zeroed on allocation, so a standalone request leaks
nothing. A compound request can leak: the offset of the next response
is advanced by the length pinned for the previous one, so a reply that
was written into the buffer and then dropped in favour of the short
error response of smb2_set_err_rsp() stays there, and the next reply is
laid over it with only the header cleared.
Report the file system id statfs() returned, which is what the field is
for. FileSysIdentifier is __le64 and f_fsid is a pair of ints, so
assemble the value first, val[0] as the low half, and convert it on the
way out.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: reject SetEA requests that do not fit the request buffer
CIFSSMBSetEA() copies the caller's extended attribute value into the
SMB request buffer without checking that it fits. The requirement is
stated in the source but was never implemented:
/*BB add length check to see if it would fit in
negotiated SMB buffer size BB */
/* if (ea_value_len > buffer_size - 512 (enough for header)) */
if (ea_value_len)
memcpy(parm_data->list.name + name_len + 1,
ea_value, ea_value_len);
The only bound applied on the way in is in cifs_xattr_set():
#define MAX_EA_VALUE_SIZE CIFSMaxBufSize
...
if (size > MAX_EA_VALUE_SIZE)
CIFSMaxBufSize is the full payload capacity of the buffer, so a value
of exactly that size leaves no room for the SMB header, the TRANS2
parameter block, the fealist header and the EA name that are written
ahead of it in the same object.
SendReceive() already enforces the correct limit on this very length:
if (in_len > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE)
but it is called after the copy has taken place. An unprivileged
setxattr(2) on an SMB1 mount with a 250-byte name and a 16384-byte
value writes 16384 bytes starting 345 bytes into a 16588-byte
cifs_request object, ending 141 bytes past it:
BUG: KASAN: slab-out-of-bounds in CIFSSMBSetEA+0xabc/0xde0
Write of size 16384 at addr ffff888003aa0159 by task init/68
__asan_memcpy+0x3c/0x60
CIFSSMBSetEA+0xabc/0xde0
cifs_xattr_set+0xd3a/0xff0
__vfs_setxattr+0x13e/0x1a0
The buggy address is located 345 bytes inside of
allocated 16588-byte region
Apply SendReceive()'s limit to the assembled request before the copy
rather than after it, and widen the byte counters so the sum cannot
wrap before it is tested.
byte_count is also tested against U16_MAX, because it is stored in the
16-bit pSMB->ByteCount. That becomes reachable when CIFSMaxBufSize is
raised at module load, where it may be set as high as 1024*127: with a
5-byte EA name and a 65521-byte value, count is exactly U16_MAX while
byte_count is 65556, and cpu_to_le16() would truncate it to 20 and
transmit a frame whose ByteCount does not match its length. Testing
byte_count covers count as well, since byte_count is the larger of the
two and count's only 16-bit consumer is written after this point.
check_add_overflow() is evaluated first so that total_len is assigned
before it is reported.
A vulnerability in pretix API endpoints allowed unauthorized referencing of gift cards by exploiting predictable internal IDs. Attackers could create payments linked to gift cards from other organizers without charging the gift card, then trigger refunds to increase the gift card's value. This flaw affects multiple versions of pretix prior to fixed releases in 2026.6.4, 2026.7.3, and 2026.8.1.
Dell PowerProtect Data Domain versions 7.7.1.0 through 8.8 (Feature Release), 7.13.1.0 through 7.13.1.80 (LTS2024), 8.3.1.0 through 8.3.1.40 (LTS2025), and 8.6.1.0 through 8.6.1.20 (LTS2026) contain an improper validation of integrity check value vulnerability. This flaw could allow a high privileged attacker with local access to bypass protection mechanisms. The vulnerability is identified as CVE-2026-90720 and has a CVSS v3.1 score of 6.7, indicating a medium severity impact. No public exploits or patches are currently documented.
A command injection vulnerability exists in the bash activation script of virtualenv when the shell option 'promptvars' is off at activation time. The vulnerability arises because the '--prompt' value is inserted into the PS1 prompt variable without proper escaping, allowing subsequent re-enabling of prompt expansion to execute arbitrary commands. This regression was introduced in virtualenv version 21.14.9 and persists through 21.14.12. The issue is fixed in version 2.5.9_6.