VB-Audio Voicemeeter & Matrix Drivers DoS via MmMapLockedPagesSpecifyCache

VB-Audio Voicemeeter, Voicemeeter Banana, and Voicemeeter Potato (versions ending in 1.1.1.9, 2.1.1.9, and 3.1.1.9 and earlier, respectively), as well as VB-Audio Matrix and Matrix Coconut (versions ending in 1.0.2.2 and 2.0.2.2 and earlier, respectively), contain a vulnerability in their virtual audio drivers (vbvoicemeetervaio64*.sys, vbmatrixvaio64*.sys, vbaudio_vmauxvaio*.sys, vbaudio_vmvaio*.sys, and vbaudio_vmvaio3*.sys). The drivers map non-paged pool memory into user space via MmMapLockedPagesSpecifyCache using UserMode access without proper exception handling. If the mapping fails, such as when a process has exhausted available virtual address space, MmMapLockedPagesSpecifyCache raises an exception that is not caught, causing a kernel crash (BSoD), typically SYSTEM_SERVICE_EXCEPTION with STATUS_NO_MEMORY. This flaw allows a local unprivileged user to trigger a denial-of-service on affected Windows systems.

Junos OS: Receipt of a specifically malformed ICMP packet causes an FPC restart

An Improper Handling of Exceptional Conditions vulnerability in packet processing of Juniper Networks Junos OS allows an unauthenticated, network-adjacent attacker sending a specifically malformed ICMP packet to cause an FPC to crash and restart, resulting in a Denial of Service (DoS). When an ICMP packet is received with a specifically malformed IP header value, the FPC receiving the packet crashes and restarts. Due to the specific type of malformed packet, adjacent upstream routers would not forward the packet, limiting the attack surface to adjacent networks. This issue only affects ICMPv4. ICMPv6 is not vulnerable to this issue. This issue does not affect AFT-based line cards such as the MPC10, MPC11, LC4800, LC9600, and MX304. This issue affects Junos OS:  * all versions before 21.2R3-S9,  * from 21.4 before 21.4R3-S10,  * from 22.2 before 22.2R3-S7,  * from 22.3 before 22.3R3-S4,  * from 22.4 before 22.4R3-S5,  * from 23.2 before 23.2R2-S3,  * from 23.4 before 23.4R2-S3,  * from 24.2 before 24.2R1-S2, 24.2R2.

SvelteKit's invalidated redirect in handle hook causes Denial-of-Service

SvelteKit is a framework for rapidly developing robust, performant web applications using Svelte. Prior to 2.57.1, redirect, when called from inside the handle server hook with a location parameter containing characters that are invalid in a HTTP header, will cause an unhandled TypeError. This could result in DoS on some platforms, especially if the location passed to redirect contains unsanitized user input. This vulnerability is fixed in 2.57.1.

Improper Input Validation

Team ENVY, a Security Research TEAM has found a flaw that allows for a remote code execution on the NVR. An attacker could inject malformed data into url input parameters to reboot the NVR. The manufacturer has released patch firmware for the flaw, please refer to the manufacturer's report for details and workarounds.

5380/5580 Denial-of-Service Vulnerability

A denial-of-service vulnerability exists in the affected products. The vulnerability could allow a remote, non-privileged user to send malicious requests resulting in a major nonrecoverable fault causing a denial-of-service.

Rockwell Automation ArmorStart® AOP Denial-of-Service Vulnerability

A security issue exists within the Studio 5000 Logix Designer add-on profile (AOP) for the ArmorStart Classic distributed motor controller, resulting in denial-of-service. This vulnerability is possible due to the input of invalid values into Component Object Model (COM) methods.

Volto affected by possible DoS by invoking specific URL by anonymous user

Volto is a React based frontend for the Plone Content Management System. In versions from 19.0.0-alpha.1 to before 19.0.0-alpha.4, 18.0.0 to before 18.24.0, 17.0.0 to before 17.22.1, and prior to 16.34.0, an anonymous user could cause the NodeJS server part of Volto to quit with an error when visiting a specific URL. The problem has been patched in versions 16.34.0, 17.22.1, 18.24.0, and 19.0.0-alpha.4. To mitigate downtime, have setup automatically restart processes that quit with an error.

Remotely exploitable DoS in Tonic `<=v0.12.2`

Tonic is a native gRPC client & server implementation with async/await support. When using tonic::transport::Server there is a remote DoS attack that can cause the server to exit cleanly on accepting a TCP/TLS stream. This can be triggered by causing the accept call to error out with errors that were not covered correctly causing the accept loop to exit. Upgrading to tonic 0.12.3 and above contains the fix.

Truncated content of messages can be leaked from matrix-appservice-irc

matrix-appservice-irc is a Node.js IRC bridge for the Matrix messaging protocol. matrix-appservice-irc before version 2.0.0 can be exploited to leak the truncated body of a message if a malicious user sends a Matrix reply to an event ID they don't have access to. As a precondition to the attack, the malicious user needs to know the event ID of the message they want to leak, as well as to be joined to both the Matrix room and the IRC channel it is bridged to. The message reply containing the leaked message content is visible to IRC channel members when this happens. matrix-appservice-irc 2.0.0 checks whether the user has permission to view an event before constructing a reply. Administrators should upgrade to this version. It's possible to limit the amount of information leaked by setting a reply template that doesn't contain the original message. See these lines `601-604` in the configuration file linked.

Nanopb does not release memory on error return when using PB_DECODE_DELIMITED

Nanopb is a small code-size Protocol Buffers implementation. When the compile time option PB_ENABLE_MALLOC is enabled, the message contains at least one field with FT_POINTER field type, custom stream callback is used with unknown stream length. and the pb_decode_ex() function is used with flag PB_DECODE_DELIMITED, then the pb_decode_ex() function does not automatically call pb_release(), like is done for other failure cases. This could lead to memory leak and potential denial-of-service. This vulnerability is fixed in 0.4.9.1.

An issue was discovered on Mercusys MW325R EU V3 MW325R(EU)_V3_1.11.0 221019 devices. A WAN attacker can make the admin interface unreachable/invisible via an unauthenticated HTTP request. Verification of the data sent by the user does not occur. The web server does not crash, but the admin interface becomes invisible, because the files necessary to display the content are no longer available. A reboot of the router is typically required to restore the correct behavior.

Panic Vulnerability in loona-hpack

loona is an experimental, HTTP/1.1 and HTTP/2 implementation in Rust on top of io-uring. `loona-hpack` suffers from the same vulnerability as the original `hpack` as documented in issue #11. All users who try to decode untrusted input using the Decoder are vulnerable to this exploit. This issue has been addressed in release version 0.4.3. All users are advised to upgrade. There are no known workarounds for this vulnerability.

Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt

golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.

HPE NonStop DISK UTIL, Local Denial of Service vulnerability

A potential security vulnerability has been identified in the HPE NonStop DISK UTIL (T9208) product. This vulnerability could be exploited to cause a denial of service (DoS) to NonStop server. It exists in all prior DISK UTIL product versions of L-series and J-series.

REE userspace code can panic TAs, leading to fTPM PCR reset and data disclosure

OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. In version 4.5.0, using a specially crafted tee-supplicant binary running in REE userspace, an attacker can trigger a panic in a TA that uses the libutee Secure Storage API. Many functions in libutee, specifically those which make up the Secure Storage API, will panic if a system call returns an unexpected return code. This behavior is mandated by the TEE Internal Core API specification. However, in OP-TEE’s implementation, return codes of secure storage operations are passed through unsanitized from the REE tee-supplicant, through the Linux kernel tee-driver, through the OP-TEE kernel, back to libutee. Thus, an attacker with access to REE userspace, and the ability to stop tee-supplicant and replace it with their own process (generally trivial for a root user, and depending on the way permissions are set up, potentially available even to less privileged users) can run a malicious tee-supplicant process that responds to storage requests with unexpected response codes, triggering a panic in the requesting TA. This is particularly dangerous for TAs built with `TA_FLAG_SINGLE_INSTANCE` (corresponding to `gpd.ta.singleInstance` and `TA_FLAG_INSTANCE_KEEP_ALIVE` (corresponding to `gpd.ta.keepAlive`). The behavior of these TAs may depend on memory that is preserved between sessions, and the ability of an attacker to panic the TA and reload it with a clean memory space can compromise the behavior of those TAs. A critical example of this is the optee_ftpm TA. It uses the kept alive memory to hold PCR values, which crucially must be non-resettable. An attacker who can trigger a panic in the fTPM TA can reset the PCRs, and then extend them PCRs with whatever they choose, falsifying boot measurements, accessing sealed data, and potentially more. The impact of this issue depends significantly on the behavior of affected TAs. For some, it could manifest as a denial of service, while for others, like the fTPM TA, it can result in the disclosure of sensitive data. Anyone running the fTPM TA is affected, but similar attacks may be possible on other TAs that leverage the Secure Storage API. A fix is available in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f.

Elastic Defend Improper Handling of Alternate Encoding Leads to Crash

Improper handling of alternate encoding occurs when Elastic Defend on Windows systems attempts to scan a file or process encoded as a multibyte character. This leads to an uncaught exception causing Elastic Defend to crash which in turn will prevent it from quarantining the file and/or killing the process.

React Router allows a DoS via cache poisoning by forcing SPA mode

React Router is a router for React. Starting in version 7.2.0 and prior to version 7.5.2, it is possible to force an application to switch to SPA mode by adding a header to the request. If the application uses SSR and is forced to switch to SPA, this causes an error that completely corrupts the page. If a cache system is in place, this allows the response containing the error to be cached, resulting in a cache poisoning that strongly impacts the availability of the application. This issue has been patched in version 7.5.2.

hydra-node dangerously assumes L1 event finality and does not consider failed transactions

Hydra is a layer-two scalability solution for Cardano. Prior to version 0.22.0, the process assumes L1 event finality and does not consider failed transactions. Currently, Cardano L1 is monitored for certain events which are necessary for state progression. At the moment, Hydra considers those events as finalized as soon as they are recognized by the node participants making such transactions the target of re-org attacks. The system does not currently consider the fact that failed transactions on the Cardano L1 can indeed appear in blocks because these transactions are so infrequent. This issue has been patched in version 0.22.0.

Malicious Matrix homeserver can leak truncated message content of messages it shouldn't have access to

matrix-appservice-irc is a Node.js IRC bridge for the Matrix messaging protocol. The fix for GHSA-wm4w-7h2q-3pf7 / CVE-2024-32000 included in matrix-appservice-irc 2.0.0 relied on the Matrix homeserver-provided timestamp to determine whether a user has access to the event they're replying to when determining whether or not to include a truncated version of the original event in the IRC message. Since this value is controlled by external entities, a malicious Matrix homeserver joined to a room in which a matrix-appservice-irc bridge instance (before version 2.0.1) is present can fabricate the timestamp with the intent of tricking the bridge into leaking room messages the homeserver should not have access to. matrix-appservice-irc 2.0.1 drops the reliance on `origin_server_ts` when determining whether or not an event should be visible to a user, instead tracking the event timestamps internally. As a workaround, it's possible to limit the amount of information leaked by setting a reply template that doesn't contain the original message.

quic-go has Client Crash Due to Premature HANDSHAKE_DONE Frame

quic-go is an implementation of the QUIC protocol in Go. In versions prior to 0.49.0, 0.54.1, and 0.55.0, a misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. This was observed in the wild with certain server implementations. quic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. Versions 0.49.0, 0.54.1, and 0.55.0 discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames.