| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Backstage is an open framework for building developer portals. Prior to 3.3.1, 3.4.1, 4.0.3 and 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by improper task state validation in scaffolder backend. An authenticated user with permission to create and access Scaffolder tasks may, under specific timing and deployment conditions, affect files accessible to the Backstage backend. If backend application files are writable, the confidentiality, integrity, and availability of the backend may be compromised. This issue is fixed in versions 3.3.1, 3.4.1, 4.0.3 and 4.1.0. |
| Race condition in V8 in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: coredump: Quiesce dump work on unregister
hci_devcd_handle_pkt_init() arms dump_timeout and coredump producers
queue dump_rx without holding an hdev reference. Unregister leaves both
works live, so disconnecting during an active dump lets them access hdev
after hci_release_dev() frees it.
Shut down coredump processing during unregister. Close the producer gate
under dump_q.lock before disabling both works, then free the active buffer
and queued packets under hci_dev_lock. Serializing the gate with enqueue
prevents controller-specific workers from adding packets after the final
purge. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained
hci_send_acl(), hci_send_sco() and hci_send_iso() queue hdev->tx_work
unconditionally. They can run from the L2CAP/SCO/ISO socket send path
while hci_dev_close_sync() is draining hdev->workqueue (HCIDEVDOWN
racing with a socket write). Since that queue_work() is not chained
work from the tx_work worker itself, __queue_work() sees the queue
marked __WQ_DRAINING, warns "cannot queue %ps on wq %s", and drops
the work:
WARNING: CPU: 1 PID: 5985 at kernel/workqueue.c:2352 __queue_work
Call Trace:
queue_work_on
l2cap_chan_send
l2cap_sock_sendmsg
...
hci_dev_close_sync() already sets HCI_CMD_DRAIN_WORKQUEUE before
draining, but only hci_cmd_work() and handle_cmd_cnt_and_timer()
check it before queuing. Route the tx_work producers through the
same guard via a shared hci_sched_tx() helper. |
| Race condition in Chromoting in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to potentially bypass system access restrictions via crafted network traffic. (Chromium security severity: Low) |
| Canimaan Software ClamXAV versions 3.3 - 3.11 contains a local privilege escalation vulnerability in the Privileged Helper Tool caused by a race condition and insufficient file validation, allowing a local attacker to execute arbitrary code with system privileges. Fixed in 3.11.1. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: bcd2000: Fix race between rawmidi and disconnect
Although we tried to fix the potential UAF issues at USB disconnect on
bcd2000 driver, there is still an overlooked case -- namely, when a
rawmidi trigger callback has been already running at USB disconnect
handling, the in-flight function (e.g. bcd2000_midi_send()) could
still access the URB, because the previous URB NULL-check & clearance
was considered only for the URB complete callbacks, but not about the
parallel rawmidi operations.
For addressing the race, this patch introduced a new spinlock that
covers each rawmidi operation as well as the rawmidi handling in the
complete callback. The URB is cleared with the lock, so it guarantees
that the pending rawmidi task already finished or a NULL check is
effective. |
| In the Linux kernel, the following vulnerability has been resolved:
tcp: Don't call skb_clone_and_charge_r() for close()d listener in tcp_v6_do_rcv().
tcp_v6_do_rcv() no longer calls skb_clone_and_charge_r() for
TCP_LISTEN since commit 073d89808c06 ("net: fix data-races around
sk->sk_forward_alloc").
However, there is still a small race window between tcp_v6_rcv()
and tcp_v6_do_rcv(), where concurrent close() changes TCP_LISTEN
to TCP_CLOSE, causing skb_clone_and_charge_r() to be called
locklessly and resulting in the splat below. [0]
Let's avoid calling skb_clone_and_charge_r() for TCP_CLOSE as well.
This is fine for non-listeners because tcp_rcv_state_process()
drops skb for TCP_CLOSE and opt_skb was freed immediately anyway.
[0]:
sk->sk_forward_alloc
WARNING: net/ipv4/af_inet.c:162 at inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:162, CPU#1: ksoftirqd/1/28
Modules linked in:
CPU: 1 UID: 0 PID: 28 Comm: ksoftirqd/1 Not tainted 7.2.0 #17 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
RIP: 0010:inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:162
Code: 3d 49 ff e9 06 fd ff ff e8 d0 5b 83 f8 90 0f 0b 90 e9 35 fe ff ff e8 c2 5b 83 f8 90 0f 0b 90 e9 c5 fe ff ff e8 b4 5b 83 f8 90 <0f> 0b 90 e9 04 ff ff ff e8 a6 5b 83 f8 90 0f 0b 90 e9 65 fe ff ff
RSP: 0018:ffffc90000677bb8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8880117bde80 RCX: ffffffff8957eb41
RDX: ffff88801dad5d00 RSI: ffffffff8957ec3c RDI: 0000000000000005
RBP: 00000000fffff000 R08: ffffffff8957eb41 R09: 00000000fffff000
R10: 0000000000000005 R11: 0000000000000000 R12: dffffc0000000000
R13: ffff8880117bdf10 R14: ffffffff81c08eb7 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880d7ae5000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f93a1021138 CR3: 00000000207a9000 CR4: 0000000000350ef0
Call Trace:
<TASK>
__sk_destruct+0x82/0xae0 net/core/sock.c:2356
rcu_do_batch kernel/rcu/tree.c:2645 [inline]
rcu_core+0x59c/0x1100 kernel/rcu/tree.c:2897
handle_softirqs+0x1e4/0x9b0 kernel/softirq.c:622
run_ksoftirqd kernel/softirq.c:1076 [inline]
run_ksoftirqd+0x38/0x60 kernel/softirq.c:1068
smpboot_thread_fn+0x458/0xc80 kernel/smpboot.c:160
kthread+0x396/0x4a0 kernel/kthread.c:436
ret_from_fork+0x8e0/0xe40 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK> |
| Wasmtime is a runtime for WebAssembly. From 46.0.0 until 46.0.2 and 47.0.3, fuel and epoch preemption checks inside bulk operations including memory.copy, table.grow, and array.copy can expose invalid intermediate state when an embedder mutates a Store in Store::epoch_deadline_callback or continues using a Store after cancellation or a trap. A cancelled non-nullable table growth can leave null elements, linear-memory growth during memory.copy can invalidate retained raw pointers, and callback-triggered garbage collection during array.copy can invalidate GC pointers, resulting in a crash, invalid memory access, or GC heap corruption. Embeddings whose callbacks only access the host data in Store<T>, and embeddings that discard a Store after timeout or epoch deadline, are not affected. This issue is fixed in versions 46.0.2 and 47.0.3. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: ibss: ref BSS entry for joined event
When the IBSS is joined, we only record the BSSID/channel in the event
and look up the BSS entry when processing it. However, that's racy,
e.g. a new scan with NL80211_SCAN_FLAG_FLUSH can remove it, causing a
warning in the event work:
!bss
WARNING: net/wireless/ibss.c:37 at __cfg80211_ibss_joined+0x3d3/0x440
Workqueue: cfg80211 cfg80211_event_work
cfg80211_process_wdev_events+0x39f/0x5b0 net/wireless/util.c:1144
cfg80211_process_rdev_events+0xa1/0x110 net/wireless/util.c:1179
cfg80211_event_work+0x2f/0x40 net/wireless/core.c:393
Do the lookup early (the driver is expected to only join an IBSS that
has a BSS entry) and keep a reference to it. |
| Plane is an open-source project management tool. From 0.13 until 1.4.0, InstanceAdminSignUpEndpoint in apps/api/plane/license/api/views/admin.py:89-117, 173-229 uses InstanceAdmin.objects.first() for the first-admin check and performs account creation without an atomic transaction, row lock, uniqueness guard, or advisory lock. Two concurrent unauthenticated requests with different email addresses can both observe that no instance administrator exists, create separate User and InstanceAdmin rows, and receive sessions with instance-admin authority. This allows an attacker to share unrestricted instance administration with the legitimate operator. This issue is fixed in 1.4.0. |
| Concurrent execution using shared resource with improper synchronization ('race condition') vulnerability in Apache Struts. Where a localized message formats a date or time argument, the formatter retained for that message by the application-wide text provider is used by concurrently served requests without isolation, so a value belonging to one user can appear in another user's response, or the rendering can fail and surface as a server error. Applications whose localized messages format no date or time arguments are not affected.
This issue affects Apache Struts: from 2.0.0 through 2.3.37, from 2.5.0 through 2.5.33, from 6.0.0 through 6.11.0, from 7.0.0 through 7.3.0.
Users are recommended to upgrade to version 6.12.0 or 7.4.0, which fixes the issue. |
| In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_ptp: Fix napi_gro_receive() call from GC workqueue context
Currently mlxsw_sp1_ptp_ht_gc_collect() is run from the PTP
garbage-collection workqueue, rather than the NAPI poll context. For any
unmatched PTP entries carrying an SKB, it calls
mlxsw_sp1_ptp_unmatched_finish() -> mlxsw_sp1_ptp_packet_finish(). For
ingress packets, this calls mlxsw_sp_rx_listener_no_mark_func(). The end
of that function is the following:
skb->protocol = eth_type_trans(skb, skb->dev);
napi_gro_receive(mlxsw_skb_cb(skb)->rx_md_info.napi, skb);
The napi pointer is one that was placed in the SKB control block when the
trapped packet was received in the NAPI context. Later, when the GC reaps
the unmatched entry (up to MLXSW_SP1_PTP_HT_GC_TIMEOUT later), the call to
napi_gro_receive() mutates the NAPI instance's GRO list, which is unsafe
if the poll is running concurrently on another CPU.
In mlxsw_sp1_ptp_ht_gc_collect(), local_bh_disable() is called to prevent
softirq processing, but this only applies to the local CPU. Additionally,
its comment is stale. It states that mlxsw_sp1_ptp_unmatched_finish()
invokes netif_receive_skb(). This has not been accurate since the
referenced commit; this patch makes that comment accurate again.
mlxsw_pci_napi_devs_init() calls netif_threaded_enable() on the NAPI RX
net_device without any conditions. The NAPI instance's poll, which may be
running concurrent to the GC, is running as an independently-scheduled
kthread which may be on a different CPU. The call to local_bh_disable()
does not guard against this.
If a tx-timestamp timeout produces an unmatched entry (which can be easily
reproduced by running ptp4l and waiting for a port to reach the
UNCALIBRATED/SLAVE state) while the owning NAPI thread is in the middle of
a poll on another CPU, both sides mutate the GRO list concurrently, as
shown below:
[39.846] port 1 (swp1): MASTER to UNCALIBRATED on RS_SLAVE
list_add corruption. next->prev should be prev (ffff8d620faf4138), but was ffff8d624150f700. (next=ffff8d620faf4138).
kernel BUG at lib/list_debug.c:29!
Oops: invalid opcode: 0000 [#1] SMP PTI
CPU: 1 UID: 0 PID: 539 Comm: napi/mlxsw_rx-0 Not tainted 6.18.48 #1-NixOS PREEMPT(lazy)
Hardware name: Mellanox Technologies Ltd. MSN2410/VMOD0001, BIOS 4.6.5 09/13/2018
RIP: 0010:__list_add_valid_or_report+0x79/0xb0
RSP: 0018:ffffcdf8c0f27c08 EFLAGS: 00010246
RAX: 0000000000000075 RBX: ffff8d624150fd00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8d6315d1e540
RBP: ffff8d620faf4070 R08: 0000000000000000 R09: 00000000ffffdfff
R10: ffffffffa5c60fe0 R11: ffffcdf8c0f27ab8 R12: 0000000000000003
R13: 000000000000003d R14: 00000000000001bc R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8d636f63f000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000562689a60c24 CR3: 000000015f224004 CR4: 00000000001726f0
Call Trace:
<TASK>
gro_receive_skb+0xee/0x230
mlxsw_sp1_ptp_got_packet+0x61/0x140 [mlxsw_spectrum]
mlxsw_core_skb_receive+0xdf/0x1b0 [mlxsw_core]
mlxsw_pci_napi_poll_cq_rx+0x780/0x9d0 [mlxsw_pci]
__napi_poll+0x31/0x1e0
napi_threaded_poll_loop+0x16b/0x1c0
napi_threaded_poll+0x71/0xa0
kthread+0xfb/0x260
ret_from_fork+0x22d/0x260
ret_from_fork_asm+0x1a/0x30
</TASK>
Kernel panic - not syncing: Fatal exception in interrupt
The machinery that leads to this kernel panic has not been changed between
6.18.48 and mainline.
This patch adds an ingress-delivery helper for the PTP packet_finish()
path that calls netif_receive_skb() instead of napi_gro_receive().
netif_receive_skb(), unlike napi_gro_receive(), can be called from outside
of the NAPI instance's poll context, which can occur at the call site for
this path. RX stats accounting and the skb->dev assignment are still
preserved; the only change is the delivery call itself.
This removes GR
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
net/packet: clear RX owner on VNET header error
Commit 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race
condition") added rx_owner_map and made tpacket_rcv() claim a V1 or V2
ring slot before converting the virtio-net header. If the conversion
fails, the drop path leaves the slot claimed.
With a one-frame TPACKET_V2 ring, an unsupported UDP GSO packet leaves
the only slot unavailable, so the ring also drops the next valid packet.
Clear the ownership bit on this error path. TPACKET_V3 already clears
its block state here. |
| Sandbox escape due to race condition in the XPConnect component. This vulnerability was fixed in Firefox 156 and Thunderbird 156. |
| In the Linux kernel, the following vulnerability has been resolved:
ovpn: fix race between deleting interface and adding new peer
While deleting an existing ovpn interface, there is a very
narrow window where adding a new peer via netlink may cause
the netdevice to hang and prevent its unregistration.
It may happen during ovpn_dellink(), when all existing peers are
freed and the device is queued for deregistration, but a
CMD_PEER_NEW message comes in adding a new peer that takes again
a reference to the netdev.
At this point there is no way to release the device because we are
under the assumption that all peers were already released.
Fix the race condition by releasing all peers in ndo_uninit(),
when the netdevice has already been removed from the netdev
list.
Also ovpn_peer_add() has now an extra check that forces the
function to bail out if the device reg_state is not REGISTERED.
This way any incoming CMD_PEER_NEW racing with the interface
deletion routine will simply stop before adding the peer.
Note that the above check happens while holding the netdev_lock
to prevent racing netdev state changes.
ovpn_dellink() is now empty and can be removed. |
| Race condition in the DOM: Content Processes component. This vulnerability was fixed in Firefox 156, Firefox ESR 153.3, Thunderbird 156, and Thunderbird 153.3. |
| A vulnerability was detected in crossplane crossplane-runtime up to 2.2.2/2.3.2. This vulnerability affects the function Get of the file pkg/xpkg/client.go of the component ImageConfig. The manipulation results in time-of-check time-of-use. The attack may be launched remotely. Upgrading to version 2.2.3, 2.3.3 and 2.4.0-rc.1 is able to resolve this issue. The patch is identified as bee99c6cd6ca81878acca2940a2f0a02169fc208. You should upgrade the affected component. |
| Nezha from 1.8.0 before 2.3.13 contains a lock-order inversion in UpdateGroup and DeleteGroup that allows authenticated non-admin users to deadlock the alerting subsystem. Attackers can concurrently call the notification-group and batch-delete endpoints with oversized id lists to widen the race and close an ABBA cycle, permanently killing alert delivery until restart. |
| Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in WPdevelop Booking Calendar booking allows Leveraging Race Conditions.This issue affects Booking Calendar: from n/a through 11.8.4. |
