| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In OpenStack Nova before 33.0.2, the server create API does not strip certain hint data. The resulting instance has no Placement allocation. |
| Mitigation bypass in the DOM: Security component. This vulnerability was fixed in Firefox 152 and Thunderbird 152. |
| Mitigation bypass in the DOM: Security component. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12. |
| To allow builds of Python to be run from an in-tree layout (rather than
an installed file layout), the VPATH variable is defined at build time
and used to locate certain landmarks - specifically,
Modules/setup.local. When this landmark is found relative to VPATH
relative to the executable, Python assumes it is running in a source
tree and generates a different default sys.path. This code remains in
release builds, so that release-ready builds can be built in-tree.
On Windows, since builds are written to 'PCbuild/', the value of
VPATH is set to '..\..', which results in a landmark of
'..\..\Modules\setup.local'. This path is outside the install directory
of Python, and may have different permissions, potentially allowing a
low-privilege user to create the landmark and an alternative `Lib`
folder that will be discovered by an otherwise restricted install.
Such a setup occurs with the legacy default install location for all
users (in the now superseded EXE installer), due to how Windows allows
all users to create folders in the root directory of their OS drive.
Our recommended mitigation on Windows is to migrate away from the
legacy installer and use the new [Python install
manager](https://www.python.org/downloads/latest/pymanager/) to install
for the current user. Installs where the directory two levels above the
Python installation directory have equivalent permissions are unaffected
(in general, a per-user install cannot be modified at all by other
users, removing any escalation of privilege risk, and could be directly
modified by a privileged user, making the potential tampering
irrelevant). Alternative mitigations might include preemptively creating
and restricting access to a `Modules` directory. Be aware that only 3.13
and 3.14 will receive updated legacy installers - earlier fixes are only
provided as sources.
Platforms other than Windows allow VPATH to be overridden, but as they
don't usually use a separated directory in the build for binaries, are
unlikely to have a landmark reference outside of the install directory.
The landmark detection involving VPATH is a fallback for when a more
specific landmark - .\pybuilddir.txt - is absent, and was included for
compatibility. Future releases of Python will no longer include the
fallback, and so builds will need to generate or preserve the
pybuilddir.txt file in order to work in-tree. This landmark file has
been generated on Windows since 3.11, and on other platforms for longer. |
| OpenClaw before 2026.5.12 contains a notification bypass vulnerability allowing Slack reaction events to enter the agent pipeline despite disabled reaction notifications. Attackers can trigger unintended agent processing by sending reaction events when the feature is enabled, potentially leading to unauthorized processing of lower-trust input. |
| OpenClaw before 2026.5.3 contains a policy enforcement vulnerability where Zalo contacts with mutable display metadata could match allowFrom policy entries through display name changes. Attackers with mutable display names could receive agent responses intended for different Zalo identities when the feature is enabled. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix potential overflow of PCM transfer buffer
The PCM stream data in USB-audio driver is transferred over USB URB
packet buffers, and each packet size is determined dynamically. The
packet sizes are limited by some factors such as wMaxPacketSize USB
descriptor. OTOH, in the current code, the actually used packet sizes
are determined only by the rate and the PPS, which may be bigger than
the size limit above. This results in a buffer overflow, as reported
by syzbot.
Basically when the limit is smaller than the calculated packet size,
it implies that something is wrong, most likely a weird USB
descriptor. So the best option would be just to return an error at
the parameter setup time before doing any further operations.
This patch introduces such a sanity check, and returns -EINVAL when
the packet size is greater than maxpacksize. The comparison with
ep->packsize[1] alone should suffice since it's always equal or
greater than ep->packsize[0]. |
| In OpenStack Ironic 32 before 37.0.0, an unauthenticated malicious user could submit a crafted JSON string to some endpoints on the API or JSON-RPC service and effect a service crash. |
| In the Linux kernel, the following vulnerability has been resolved:
vsock: Ignore signal/timeout on connect() if already established
During connect(), acting on a signal/timeout by disconnecting an already
established socket leads to several issues:
1. connect() invoking vsock_transport_cancel_pkt() ->
virtio_transport_purge_skbs() may race with sendmsg() invoking
virtio_transport_get_credit(). This results in a permanently elevated
`vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.
2. connect() resetting a connected socket's state may race with socket
being placed in a sockmap. A disconnected socket remaining in a sockmap
breaks sockmap's assumptions. And gives rise to WARNs.
3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a
transport change/drop after TCP_ESTABLISHED. Which poses a problem for
any simultaneous sendmsg() or connect() and may result in a
use-after-free/null-ptr-deref.
Do not disconnect socket on signal/timeout. Keep the logic for unconnected
sockets: they don't linger, can't be placed in a sockmap, are rejected by
sendmsg().
[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/
[2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/
[3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/ |
| In the Linux kernel, the following vulnerability has been resolved:
ipv6: use RCU in ip6_output()
Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent
possible UAF.
We can remove rcu_read_lock()/rcu_read_unlock() pairs
from ip6_finish_output2(). |
| In the Linux kernel, the following vulnerability has been resolved:
smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().
smc_clc_prfx_match() is called from smc_listen_work() and
not under RCU nor RTNL.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dst_dev_rcu().
Note that the returned value of smc_clc_prfx_match() is not
used in the caller. |
| LangGraph SQLite Checkpoint is an implementation of LangGraph CheckpointSaver that uses SQLite DB (both sync and async, via aiosqlite). In versions 4.1.0 and prior, the JsonPlusSerializer can reconstruct Python objects from JSON checkpoint payloads. Under conditions where someone could modify checkpoint bytes at rest in the backing store, the deserialization path could reconstruct objects beyond what the application expects, which could in turn result in code execution at checkpoint load time. This is a defense-in-depth issue. The affected behavior is reachable only when checkpoint bytes at rest in the backing store can be modified by an unauthorized party. In most deployments that prerequisite already implies a serious incident; the additional concern is turning "checkpoint-store write access" into code execution in the application runtime. This issue has been fixed in version 4.1.1. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Check the untrusted offset in FF-A memory share
Verify the offset to prevent OOB access in the hypervisor
FF-A buffer in case an untrusted large enough value
[U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX]
is set from the host kernel. |
| NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_rewrite_module module. This vulnerability exists when a rewrite directive uses a regex pattern with distinct, overlapping Perl-Compatible Regular Expression (PCRE) captures (for example, ^/((.*))$) and a replacement string that references multiple such captures (for example, $1$2) in a redirect or arguments context. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. |
| FreeRDP before 3.26.0 contains a heap-buffer-overflow vulnerability in gdi_CacheToSurface that allows remote attackers to write out-of-bounds heap memory. The vulnerability occurs because rectangle validation clamps coordinates to UINT16_MAX but performs copy operations using unclamped cache entry dimensions, enabling malicious RDP servers to trigger large out-of-bounds writes and potentially achieve remote code execution or client crash. |
| In the Linux kernel, the following vulnerability has been resolved:
ipv6: use RCU in ip6_xmit()
Use RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent
possible UAF. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: video: Fix use-after-free in acpi_video_switch_brightness()
The switch_brightness_work delayed work accesses device->brightness
and device->backlight, freed by acpi_video_dev_unregister_backlight()
during device removal.
If the work executes after acpi_video_bus_unregister_backlight()
frees these resources, it causes a use-after-free when
acpi_video_switch_brightness() dereferences device->brightness or
device->backlight.
Fix this by calling cancel_delayed_work_sync() for each device's
switch_brightness_work in acpi_video_bus_remove_notify_handler()
after removing the notify handler that queues the work. This ensures
the work completes before the memory is freed.
[ rjw: Changelog edit ] |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: Prevent TOCTOU out-of-bounds write
For the following path not holding the sock lock,
sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()
make sure not to exceed bounds in case the address list has grown
between buffer allocation (time-of-check) and write (time-of-use). |
| A vulnerability exists in the ngx_http_scgi_module and ngx_http_uwsgi_module modules that may result in excessive memory allocation or an over-read of data. When scgi_pass or uwsgi_pass is configured, an unauthenticated attacker with man-in-the-middle (MITM) ability to control responses from an upstream server may be able to read the memory of the NGINX worker process or restart it. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: fix field-spanning memcpy warning in AH output
Fix field-spanning memcpy warnings in ah6_output() and
ah6_output_done() where extension headers are copied to/from IPv6
address fields, triggering fortify-string warnings about writes beyond
the 16-byte address fields.
memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16)
WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439
The warnings are false positives as the extension headers are
intentionally placed after the IPv6 header in memory. Fix by properly
copying addresses and extension headers separately, and introduce
helper functions to avoid code duplication. |
