Allocation of Resources Without Limits or Throttling

An issue was discovered in the Linux kernel 2.6.39 through 5.10.16, as used in Xen. Block, net, and SCSI backends consider certain errors a plain bug, deliberately causing a kernel crash. For errors potentially being at least under the influence of guests (such as out of memory conditions), it isn't correct to assume a plain bug. Memory allocations potentially causing such crashes occur only when Linux is running in PV mode, though. This affects drivers/block/xen-blkback/blkback.c and drivers/xen/xen-scsiback.c.Show less

In SystemSettingsValidators, there is a possible permanent denial of service due to missing bounds checks on UI settings. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11Android ID: A-156260178Show less

A vulnerability has been identified in SCALANCE W780 and W740 (IEEE 802.11n) family (All versions < V6.3). Sending specially crafted packets through the ARP protocol to an affected device could cause a partial denial-of-service, preventing the device to operate normally for a short period of time.Show less

An unauthenticated specially crafted packet sent by an attacker over the network will cause a denial-of-service (DoS) vulnerability. Vulnerability allows attacker to stop the PLC. After stopping (ERR LED flashing red), physical access to the PLC is required in order to restart the application. This issue affects: ABB AC500 V2 products with onboard Ethernet version 2.8.4 and prior versions.Show less

Http4s (http4s-blaze-server) is a minimal, idiomatic Scala interface for HTTP services. Http4s before versions 0.21.17, 0.22.0-M2, and 1.0.0-M14 have a vulnerability which can lead to a denial-of-service. Blaze-core, a library underlying http4s-blaze-server, accepts connections unboundedly on its selector pool. This has the net effect of amplifying degradation in services that are unable to handle their current request load, since incoming connections are still accepted and added to an unbounded queue. Each connection allocates a socket handle, which drains a scarce OS resource. This can also confound higher level circuit breakers which work based on detecting failed connections. http4s provides a general "MaxActiveRequests" middleware mechanism for limiting open connections, but it is enforced inside the Blaze accept loop, after the connection is accepted and the socket opened. Thus, the limit only prevents the number of connections which can be simultaneously processed, not the number of connections which can be held open. In 0.21.17, 0.22.0-M2, and 1.0.0-M14, a new "maxConnections" property, with a default value of 1024, has been added to the `BlazeServerBuilder`. Setting the value to a negative number restores unbounded behavior, but is strongly disrecommended. The NIO2 backend does not respect `maxConnections`. Its use is now deprecated in http4s-0.21, and the option is removed altogether starting in http4s-0.22. There are several possible workarounds described in the refrenced GitHub Advisory GHSA-xhv5-w9c5-2r2w.Show less

blaze is a Scala library for building asynchronous pipelines, with a focus on network IO. All servers running blaze-core before version 0.14.15 are affected by a vulnerability in which unbounded connection acceptance leads to file handle exhaustion. Blaze, accepts connections unconditionally on a dedicated thread pool. This has the net effect of amplifying degradation in services that are unable to handle their current request load, since incoming connections are still accepted and added to an unbounded queue. Each connection allocates a socket handle, which drains a scarce OS resource. This can also confound higher level circuit breakers which work based on detecting failed connections. The vast majority of affected users are using it as part of http4s-blaze-server <= 0.21.16. http4s provides a mechanism for limiting open connections, but is enforced inside the Blaze accept loop, after the connection is accepted and the socket opened. Thus, the limit only prevents the number of connections which can be simultaneously processed, not the number of connections which can be held open. The issue is fixed in version 0.14.15 for "NIO1SocketServerGroup". A "maxConnections" parameter is added, with a default value of 512. Concurrent connections beyond this limit are rejected. To run unbounded, which is not recommended, set a negative number. The "NIO2SocketServerGroup" has no such setting and is now deprecated. There are several possible workarounds described in the refrenced GitHub Advisory GHSA-xmw9-q7x9-j5qc.Show less

It was found in Moodle before version 3.10.1, 3.9.4, 3.8.7 and 3.5.16 that messaging did not impose a character limit when sending messages, which could result in client-side (browser) denial of service for users receiving very large messages.Show less

A vulnerability in the web UI of Cisco Umbrella could allow an unauthenticated, remote attacker to negatively affect the performance of this service. The vulnerability exists due to insufficient rate limiting controls in the web UI. An attacker could exploit this vulnerability by sending crafted HTTPS packets at a high and sustained rate. A successful exploit could allow the attacker to negatively affect the performance of the web UI. Cisco has addressed this vulnerability.Show less

An issue was discovered in Open Design Alliance Drawings SDK before 2021.12. A memory allocation with excessive size vulnerability exists when reading malformed DGN files, which allows attackers to cause a crash, potentially enabling denial of service (crash, exit, or restart).Show less

A vulnerability in processing of certain DHCP packets from adjacent clients on EX Series and QFX Series switches running Juniper Networks Junos OS with DHCP local/relay server configured may lead to exhaustion of DMA memory causing a Denial of Service (DoS). Over time, exploitation of this vulnerability may cause traffic to stop being forwarded, or to crashing of the fxpc process. When Packet DMA heap utilization reaches 99%, the system will become unstable. Packet DMA heap utilization can be monitored through the following command: user@junos# request pfe execute target fpc0 timeout 30 command "show heap" ID Base Total(b) Free(b) Used(b) % Name -- ---------- ----------- ----------- ----------- --- ----------- 0 213301a8 536870488 387228840 149641648 27 Kernel 1 91800000 8388608 3735120 4653488 55 DMA 2 92000000 75497472 74452192 1045280 1 PKT DMA DESC 3 d330000 335544320 257091400 78452920 23 Bcm_sdk 4 96800000 184549376 2408 184546968 99 Packet DMA <--- 5 903fffe0 20971504 20971504 0 0 Blob An indication of the issue occurring may be observed through the following log messages: Dec 10 08:07:00.124 2020 hostname fpc0 brcm_pkt_buf_alloc:523 (buf alloc) failed allocating packet buffer Dec 10 08:07:00.126 2020 hostname fpc0 (buf alloc) failed allocating packet buffer Dec 10 08:07:00.128 2020 hostname fpc0 brcm_pkt_buf_alloc:523 (buf alloc) failed allocating packet buffer Dec 10 08:07:00.130 2020 hostnameC fpc0 (buf alloc) failed allocating packet buffer This issue affects Juniper Networks Junos OS on EX Series and QFX Series: 17.4R3 versions prior to 17.4R3-S3; 18.1R3 versions between 18.1R3-S6 and 18.1R3-S11; 18.2R3 versions prior to 18.2R3-S6; 18.3R3 versions prior to 18.3R3-S4; 18.4R2 versions prior to 18.4R2-S5; 18.4R3 versions prior to 18.4R3-S6; 19.1 versions between 19.1R2 and 19.1R3-S3; 19.2 versions prior to 19.2R3-S1; 19.3 versions prior to 19.3R2-S5, 19.3R3; 19.4 versions prior to 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S2, 20.2R2. Junos OS versions prior to 17.4R3 are unaffected by this vulnerability.Show less

Jenkins 2.274 and earlier, LTS 2.263.1 and earlier does not limit sizes provided as query parameters to graph-rendering URLs, allowing attackers to request crafted URLs that use all available memory in Jenkins, potentially leading to out of memory errors.Show less

NVIDIA Virtual GPU Manager NVIDIA vGPU manager contains a vulnerability in the vGPU plugin in which it allows guests to allocate some resources for which the guest is not authorized, which may lead to integrity and confidentiality loss, denial of service, or information disclosure. This affects vGPU version 8.x (prior to 8.6) and version 11.0 (prior to 11.3).Show less

An attacker-controlled memory allocation size can be passed to the C++ new operator in the CServerManager::HandleBrowseLoadIconStreamRequest in messaging.dll. This can be done by sending a specially crafted message to 127.0.0.1:7153. Observed in FactoryTalk Linx 6.11. All versions of FactoryTalk Linx are affected.Show less

An attacker-controlled memory allocation size can be passed to the C++ new operator in RnaDaSvr.dll by sending a specially crafted ConfigureItems message to TCP port 4241. This will cause an unhandled exception, resulting in termination of RSLinxNG.exe. Observed in FactoryTalk 6.11. All versions of FactoryTalk Linx are affected.Show less

Arm Compiler 5 through 5.06u6 has an error in a stack protection feature designed to help spot stack-based buffer overflows in local arrays. When this feature is enabled, a protected function writes a guard value to the stack prior to (above) any vulnerable arrays in the stack. The guard value is checked for corruption on function return; corruption leads to an error-handler call. In certain circumstances, the reference value that is compared against the guard value is itself also written to the stack (after any vulnerable arrays). The reference value is written to the stack when the function runs out of registers to use for other temporary data. If both the reference value and the guard value are written to the stack, then the stack protection will fail to spot corruption when both values are overwritten with the same value. For both the reference value and the guard value to be corrupted, there would need to be both a buffer overflow and a buffer underflow in the vulnerable arrays (or some other vulnerability that causes two separated stack entries to be corrupted).Show less

An issue was discovered in Xen XAPI before 2020-12-15. Certain xenstore keys provide feedback from the guest, and are therefore watched by toolstack. Specifically, keys are watched by xenopsd, and data are forwarded via RPC through message-switch to xapi. The watching logic in xenopsd sends one RPC update containing all data, any time any single xenstore key is updated, and therefore has O(N^2) time complexity. Furthermore, message-switch retains recent (currently 128) RPC messages for diagnostic purposes, yielding O(M*N) space complexity. The quantity of memory a single guest can monopolise is bounded by xenstored quota, but the quota is fairly large. It is believed to be in excess of 1G per malicious guest. In practice, this manifests as a host denial of service, either through message-switch thrashing against swap, or OOMing entirely, depending on dom0's configuration. (There are no quotas in xenopsd to limit the quantity of keys that result in RPC traffic.) A buggy or malicious guest can cause unreasonable memory usage in dom0, resulting in a host denial of service. All versions of XAPI are vulnerable. Systems that are not using the XAPI toolstack are not vulnerable.Show less