Arthurscchan

In the C-language cryptographic library liboqs, the `OQS KEM encaps derand` function can dereference an uninitialized `encaps derand` function pointer. This occurs when the function is called on specific NTRU schemes (NTRU-HPS-2048-509, NTRU-HPS-2048-677, NTRU-HPS-4096-821, NTRU-HPS-4096-1229, NTRU-HRSS-701, or NTRU-HRSS-1373) because these schemes do not support derandomized encapsulation. The issue arises because `OQS KEM` objects are allocated without zero initialization, and the wrapper in `src/kem/kem.c` only verifies that the `OQS KEM` pointer is non-null before executing the residual heap value. This can lead to a calling-process crash and denial of service if an application instantiates one of the affected NTRU KEMs and invokes `OQS KEM encaps derand` on it.

An unauthenticated remote attacker can cause a denial of service in the HTTP/2 server. The issue occurs because the `handle http frame header()` function unconditionally clears the connection stream binding, and the `enter http frame continuation state()` function fails to re-bind it when processing a CONTINUATION frame. This leads to a null pointer dereference in two specific paths: when `send headers frame()` is called via `send http2 404()` or `send http2 405()` for unregistered resources or unsupported methods, and when `handle http2 dynamic resource()` processes POST, PUT, or PATCH requests to registered dynamic resources. The vulnerability can be triggered by sending a stray CONTINUATION frame with END HEADERS set or a legitimate split header block. This results in a write to a fixed low memory address, causing the system to fault and halt.

The submission-queue verifier `rtio vrfy sqe()` in `subsys/rtio/rtio syscalls.c` incorrectly processes buffer permission checks. Due to a logic error using the `&=` operator with the `K SYSCALL MEMORY()` macro, the verifier accepts buffers that are inaccessible to the calling thread and rejects legitimate thread-owned buffers. This issue affects images built with `CONFIG USERSPACE` and is triggered via the `rtio sqe copy in get handles()` system call or the `rtio sqe copy in()` wrapper. An attacker with an RTIO context and an `rtio iodev` object can submit a crafted Submission Queue Element (SQE) pointing to arbitrary kernel memory. Because downstream handlers in I2C, I3C, and SPI drivers dereference these pointers with supervisor privileges, this can lead to: - Arbitrary kernel write: Using `RTIO OP RX` to write peripheral data into chosen kernel memory. - Kernel memory disclosure: Using `RTIO OP TX` to send kernel memory over the bus. - Kernel fault: Providing a pointer to unmapped memory. This allows a complete escape from the user-mode isolation boundary.

Two RTIO syscall verifiers in `subsys/rtio/rtio syscalls.c` fail to validate user-supplied pointers before the kernel writes through them. The function `z vrfy rtio sqe cancel()` performs no validation, allowing a user-mode thread on a `CONFIG USERSPACE` build to set a specific bit in a 16-bit word at an arbitrary address in kernel memory, which can lead to privilege escalation. Additionally, the function `z vrfy rtio sqe copy in get handles()` only performs a NULL-check on the handle out-parameter without a `K SYSCALL MEMORY WRITE` check, enabling a user thread with a granted RTIO context to force the kernel to store a pointer value at an arbitrary address.

The software has a permissive Cross-Origin Resource Sharing (CORS) configuration that trusts all ports on localhost and 127.0.0.1 with credentials, regardless of the `service.publicurl` setting. This allows an attacker controlling a page on any localhost port to send a credentialed request to the token refresh endpoint and retrieve the bearer JSON Web Token (JWT), which is a compact, URL-safe means of representing claims to be transferred between two parties, leading to full account takeover of the logged-in user.

PJSIP, a multimedia communication library written in C, contains a heap use-after-free issue within its event subscription framework, specifically in the `evsub.c` file. This issue is triggered by a presence unsubscription request—a SUBSCRIBE request with an Expires value of 0. Successful exploitation could lead to a crash or potentially code execution.

PJSIP, a multimedia communication library written in C, contains a Heap-based Buffer Overflow vulnerability in its H.264 unpacketizer. The issue arises when processing malformed SRTP packets, where the unpacketizer reads a 2-byte NAL unit size field without verifying that both bytes are within the payload buffer boundaries. This affects applications receiving video using H.264. The vulnerability allows remote attackers to potentially crash applications or execute code without authentication.

PJSIP, a multimedia communication library, contains a heap buffer underflow issue in its H.264 packetizer. This occurs when processing H.264 bitstreams lacking NAL unit start codes, leading to unchecked pointer arithmetic and potential memory access outside the allocated buffer. Exploitation of this issue, through malformed H.264 video sent over a network, can result in crashes or code execution.

The issue is a deserialization problem in the `read` method of the `SparseMatrix` class, which can lead to various privilege escalations depending on the circumstances. This method takes an `InputStream` and returns a `SparseMatrix` object. Users are vulnerable if they import non-controlled serialized `SparseMatrix` objects. This can be particularly problematic in multi-tenant applications where users with different privilege levels can submit an `InputStream` to be parsed into a `SparseMatrix`, or when using the method for a local tool with `InputStream` from external sources.

Name of the Vulnerable Software and Affected Versions: com.powsybl:powsybl-iidm-criteria versions 6.3.0 through 6.7.1 com.powsybl:powsybl-contingency-api versions 5.0.0 through 5.0.0 Description: The issue is a potential polynomial Regular Expression Denial of Service (ReDoS) vulnerability in the RegexCriterion class. This class compiles and evaluates an unvalidated, user-supplied regular expression against the identifier of an Identifiable object via Pattern.compile(regex).matcher(id).find(). If successfully exploited, a malicious actor can cause significant CPU exhaustion through repeated or recursive filter(...) calls — especially if performed over large network models or filtering operations. Recommendations: For com.powsybl:powsybl-iidm-criteria versions 6.3.0 through 6.7.1, update to version 6.7.2 or higher. For com.powsybl:powsybl-contingency-api versions 5.0.0, update to a version higher than 5.0.0, however, the exact fixed version for this component is not specified. As a temporary workaround, consider restricting the use of the RegexCriterion class until a patch is available. Avoid using untrusted regular expressions and potentially attacker-controlled identifiers in the RegexCriterion class to minimize the risk of exploitation.

The issue concerns an XML external entity (XXE) attack and a server-side request forgery (SSRF) attack in certain places of powsybl-core XML parsing. This allows an attacker to elevate their privileges to read files that they do not have permissions to, including sensitive files on the system. The vulnerable class is `com.powsybl.commons.xml.XmlReader`, which is considered untrusted in use cases where untrusted users can submit their XML to the vulnerable methods. This can be a multi-tenant application that hosts many different users, perhaps with different privilege levels.

The issue is a potential polynomial Regular Expression Denial of Service (ReDoS) vulnerability in the PowSyBl's DataSource mechanism. This vulnerability can be exploited when the `listNames(String regex)` method is called on a DataSource with a user-supplied regular expression, allowing a malicious actor to cause significant CPU consumption due to regex backtracking. The attack requires control over the regex input and influence over the file/resource names being matched. In a multi-tenant environment, this can degrade the performance and availability of the server, affecting other users of the application.

The issue exists in the session removal process of @festify/secure-session. When a session is deleted, it is marked for deletion, but if an attacker gains access to the cookie, they could keep using it forever. The plugin creates a secure stateless cookie session for Fastify, encrypting data in the session with a secret key and attaching the ciphertext as a cookie value. When an encrypted cookie with a matching session name is provided with subsequent requests, it decrypts the ciphertext to get the data and creates a new session.