| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Unbounded memory allocation in the CRYPTO frame reassembler in s2n-quic before 1.8.2 may allow an unauthenticated remote actor to cause a denial of service (degraded availability) by sending crafted QUIC Initial packets.
To remediate this issue, users should upgrade to v1.8.2. |
| When an application opts into DelegatingDeserializer, a producer can grow the consumer's heap without bound by sending records with unique random spring.kafka.serialization.selector header values, eventually causing GC thrash and OutOfMemoryError.
Affected versions:
Spring for Apache Kafka 4.0.0 through 4.0.5; 3.3.0 through 3.3.15; 3.2.0 through 3.2.13; 2.9.0 through 2.9.13; 2.8.0 through 2.8.11. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix bo leak in xe_dma_buf_init_obj() on allocation failure
When drm_gpuvm_resv_object_alloc() fails, the pre-allocated storage bo
is not freed. Add xe_bo_free(storage) before returning the error.
xe_dma_buf_init_obj() calls xe_bo_init_locked(), which frees the bo on
error. Therefore, xe_dma_buf_init_obj() must also free the bo on its own
error paths. Otherwise, since xe_gem_prime_import() cannot distinguish
whether the failure originated from xe_dma_buf_init_obj() or from
xe_bo_init_locked(), it cannot safely decide whether the bo should be
freed.
Add comments documenting the ownership semantics: on success, ownership
of storage is transferred to the returned drm_gem_object; on failure,
storage is freed before returning.
v2: Add comments to explain the free logic.
(cherry picked from commit 78a6c5f899f22338bbf48b44fb8950409c5a69b9) |
| In the Linux kernel, the following vulnerability has been resolved:
EDAC/versalnet: Fix device name memory leak
The device name allocated via kzalloc() in init_one_mc() is assigned to
dev->init_name but never freed on the normal removal path. device_register()
copies init_name and then sets dev->init_name to NULL, so the name pointer
becomes unreachable from the device. Thus leaking memory.
Use a stack-local char array instead of using kzalloc() for name. |
| Uncontrolled resource consumption in ASP.NET Core allows an unauthorized attacker to deny service over a network. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import()
When xe_dma_buf_init_obj() fails, the attachment from
dma_buf_dynamic_attach() is not detached. Add dma_buf_detach() before
returning the error. Note: we cannot use goto out_err here because
xe_dma_buf_init_obj() already frees bo on failure, and out_err would
double-free it.
(cherry picked from commit a828eb185aac41800df8eae4b60501ccc0dbbe51) |
| Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. In versions 8.2.6.4 and prior, the HAProxy section-save endpoints (POST /api/service/haproxy/<server_id>/section/<section_type> and the PUT / global / defaults variants) accept a JSON option field that is not validated, not escaped, and is rendered verbatim into the generated HAProxy configuration via the section.j2, global.j2, and defaults.j2 Ansible templates. Because Roxy-WI then pushes the generated config to the load balancer and runs systemctl reload haproxy, an authenticated user with role ≤ 3 (user) can inject arbitrary HAProxy directives into the config that runs on every load balancer their group manages — including option external-check + external-check command /bin/bash -c '…', which gives remote code execution on the load balancer as the haproxy user on every health-check tick. At time of publication, there are no publicly available patches. |
| FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to version 1.11.0, FreeSWITCH's bundled XML parser expands nested <!ENTITY> declarations without a depth or count bound, so a small DTD can describe a body that expands exponentially ("billion laughs"). The PIDF body of a SIP PUBLISH is fed to this parser before any digest check, letting an unauthenticated network attacker force unbounded CPU and memory consumption with a single request. This issue has been patched in version 1.11.0. |
| OS Command Injection Remote Code Execution Vulnerability in API in Progress ADC Products allows an un-authenticated attacker to execute arbitrary commands on the LoadMaster appliance by exploiting unsanitized input in multiple command endpoints |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix nvkm_device leak on aperture removal failure
When aperture_remove_conflicting_pci_devices() fails during probe, the
error path returns directly without unwinding the nvkm_device that was
just allocated by nvkm_device_pci_new(). This leaks both the device
wrapper and the pci_enable_device() reference taken inside it.
Jump to the existing fail_nvkm label so nvkm_device_del() runs and
balances both. The leak was introduced when the intermediate
nvkm_device_del() between detection and aperture removal was dropped
in favor of creating the pci device once. |
| In the Linux kernel, the following vulnerability has been resolved:
Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare"
This reverts commit ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use
mmap_prepare") with conflict resolution to account for changes in commit
ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare").
The patch incorrectly handled hugetlb VMA lock allocation at the
mmap_prepare stage, where a failed allocation occurring after mmap_prepare
is called might result in the lock leaking.
There is no risk of a merge causing a similar issues, as
VMA_DONTEXPAND_BIT is set for hugetlb mappings.
As a first step in addressing this issue, simply revert the change so we
can rework how we do this having corrected the underlying issues.
We maintain the VMA flags changes as best we can, accounting for the fact
that we were working with a VMA descriptor previously and propagating
like-for-like changes for this.
Note that we invoke vma_set_flags() and do not call vma_start_write() as
vm_flags_set() does. This is OK as it's being done in an .mmap hook where
the VMA is not yet linked into the tree so nobody else can be accessing
it. |
| In the Linux kernel, the following vulnerability has been resolved:
8021q: delete cleared egress QoS mappings
vlan_dev_set_egress_priority() currently keeps cleared egress
priority mappings in the hash as tombstones. Repeated set/clear cycles
with distinct skb priorities therefore accumulate mapping nodes until
device teardown and leak memory.
Delete mappings when vlan_prio is cleared instead of keeping tombstones.
Now that the egress mapping lists are RCU protected, the node can be
unlinked safely and freed after a grace period. |
| Applications which accept user-supplied Spring Expression Language (SpEL) expressions may be vulnerable to a Denial of Service (DoS) attack if the evaluation of a SpEL expression triggers unbounded cache growth.
Affected versions:
Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Recover from panthor_gpu_flush_caches() failures
We have seen a few cases where the whole memory subsystem is blocked
and flush operations never complete. When that happens, we want to:
- schedule a reset, so we can recover from this situation
- in the reset path, we need to reset the pending_reqs so we can send
new commands after the reset
- if more panthor_gpu_flush_caches() operations are queued after
the timeout, we skip them and return -EIO directly to avoid needless
waits (the memory block won't miraculously work again)
Note that we drop the WARN_ON()s because these hangs can be triggered
with buggy GPU jobs created by the UMD, and there's no way we can
prevent it. We do keep the error messages though.
v2:
- New patch
v3:
- Collect R-b
- Explicitly mention the fact we dropped the WARN_ON()s in the commit
message
v4:
- No changes |
| Microsoft is aware of a security feature bypass vulnerability in Windows publicly referred to as "YellowKey". The proof of concept for this vulnerability has been made public violating coordinated vulnerability best practices.
We are issuing this CVE to provide mitigation guidance that can be implemented to protect against this vulnerability until the security update is made available.
Mitigation FAQs
Should I leverage the temporary mitigation?
Microsoft recommends that you consider implementing these mitigations if you are concerned your devices and data are at risk of being compromised or stolen. For example, if your organization’s employees take their work devices home or on business travel.
What impact to service availability/management could be caused by implementing the mitigations?
Implementing these mitigations will not impact service availability or management operations.
Do customers need to revert the changes made to mitigate the vulnerability once the security update to protect against this vulnerability is available?
No. The security update will maintain the mitigation's behavior once the security update is installed.
I am using TPM+PIN, am I at risk of this vulnerability being exploited
No, if you are using TPM+PIN the vulnerability is not exploitable. |
| Windows Hyper-V Denial of Service Vulnerability |
| Visual Studio Code for Linux Remote Code Execution Vulnerability |
| Hermes WebUI before version 0.51.270 contains a resource exhaustion vulnerability that allows unauthenticated remote attackers to degrade service availability by repeatedly calling the passkey options endpoint without completing assertion. Attackers can send unlimited POST requests to the authentication endpoint, causing unbounded growth of the challenge store file and excessive CPU and disk I/O through repeated JSON file rewrites. |
| A vulnerability was detected in D-Link DWR-M920 up to 1.1.50. The affected element is the function sub_41CF20 of the file /boafrm/formUSSDSetup. The manipulation of the argument ussdValue results in command injection. It is possible to launch the attack remotely. The exploit is now public and may be used. |
| A security vulnerability has been detected in GL.iNet GL-MT3000 4.4.5. The impacted element is the function rpc_sys of the file /cgi-bin/luci/rpc of the component LuCI JSON-RPC Interface. Such manipulation leads to command injection. The attack may be performed from remote. Upgrading to version 4.8.1 is sufficient to resolve this issue. Upgrading the affected component is advised. The vendor confirms: "The issue discovered by the vulnerability researcher on older firmware versions(4.4.5) has actually been fixed and mitigated in the new version. According to the latest firmware fixes, by default, firmware versions after 4.7.13 do not install LuCI, so this vulnerability cannot be exploited." |
