Use After Free vulnerability in Arm Ltd Bifrost GPU Kernel Driver, Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user process to perform valid GPU memory processing operations to access already freed memory.

This issue affects Bifrost GPU Kernel Driver: from r41p0 through r49p5, from r50p0 through r51p0, from r54p1 through r54p2; Valhall GPU Kernel Driver: from r41p0 through r49p5, from r50p0 through r54p3, r55p0; Arm 5th Gen GPU Architecture Kernel Driver: from r41p0 through r49p5, from r50p0 through r54p3, r55p0.

Use After Free vulnerability in Arm Ltd Bifrost GPU Kernel Driver, Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user process to perform valid GPU memory processing operations to access already freed memory.

This issue affects Bifrost GPU Kernel Driver: from r41p0 through r49p5, from r50p0 through r51p0, from r54p1 through r54p2; Valhall GPU Kernel Driver: from r41p0 through r49p5, from r50p0 through r54p3, r55p0; Arm 5th Gen GPU Architecture Kernel Driver: from r41p0 through r49p5, from r50p0 through r54p3, r55p0.

On the Trusted Firmware-M (TF-M) 2 through 2.3.0 platform before 00d1b3e, mailbox initialization on PSOC64 and RP2350 accepts a non-secure, unvalidated, supplied pointer.

Mbed TLS before 3.6.4 has a NULL pointer dereference because mbedtlsasn1storenameddata can trigger conflicting data with val.p of NULL but val.len greater than zero.

Mbed TLS before 3.6.4 has a PEM parsing one-byte heap-based buffer underflow, in mbedtlspemreadbuffer and two mbedtlspkparse functions, via untrusted PEM input.

In MbedTLS 3.3.0 before 3.6.4, mbedtlslmsverify may accept invalid signatures if hash computation fails and internal errors go unchecked, enabling LMS (Leighton-Micali Signature) forgery in a fault scenario. Specifically, unchecked return values in mbedtlslmsverify allow an attacker (who can induce a hardware hash accelerator fault) to bypass LMS signature verification by reusing stale stack data, resulting in acceptance of an invalid signature. In mbedtlslmsverify, the return values of the internal Merkle tree functions createmerkleleafvalue and createmerkleinternalvalue are not checked. These functions return an integer that indicates whether the call succeeded or not. If a failure occurs, the output buffer (Tccandidaterootnode) may remain uninitialized, and the result of the signature verification is unpredictable. When the software implementation of SHA-256 is used, these functions will not fail. However, with hardware-accelerated hashing, an attacker could use fault

Mbed TLS before 3.6.4 allows a use-after-free in certain situations of applications that are developed in accordance with the documentation. The function mbedtlsx509stringtonames() takes a head argument that is documented as an output argument. The documentation does not suggest that the function will free that pointer; however, the function does call mbedtlsasn1freenameddatalist() on that argument, which performs a deep free(). As a result, application code that uses this function (relying only on documented behavior) is likely to still hold pointers to the memory blocks that were freed, resulting in a high risk of use-after-free or double-free. In particular, the two sample programs x509/certwrite and x509/certreq are affected (use-after-free if the san string contains more than one DN).

Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.

An issue was discovered in Mbed TLS 2.18.0 through 2.28.x before 2.28.8 and 3.x before 3.6.0 and Mbed Crypto. The PSA Crypto API mishandles shared memory.

Mbed TLS 2.x before 2.28.5 and 3.x before 3.5.0 has a Buffer Overflow.

In Mbed TLS through 4.0.0, there is a compiler-induced timing side channel (in RSA and CBC/ECB decryption) that only occurs with LLVM's select-optimize feature. TF-PSA-Crypto through 1.0.0 is also affected.

Mbed TLS before 3.6.6 and TF-PSA-Crypto before 1.1.0 misuse seeds in a Pseudo-Random Number Generator (PRNG).

The ARM PL011 UART driver in drivers/serial/uartpl011.c fails to acknowledge receive error interrupts. On the PL011, the framing, parity, break, and overrun error interrupts (PL011IMSCERRORMASK) are cleared only by writing the interrupt-clear register UARTICR; reading the data register clears the RX interrupt and the per-byte RSR status but not the error interrupt status in MIS. The interrupt service routine pl011isr() acknowledged only the CTS modem-status interrupt and never wrote icr for the error bits, so an asserted error interrupt remains pending after the ISR returns.

When an application enables error-interrupt reporting via the public uartirqerrenable() API, an attacker who controls the serial peer can deterministically assert these error bits by injecting line errors on the RX line — a baud/stop-bit mismatch or mid-character break (framing/break error), a flipped parity bit (parity error), or FIFO flooding (overrun error). Because the error interrupt is never cleared, the interrupt line stays asserted and the CPU re-enters pl011isr() immediately and indefinitely, producing an interrupt-storm livelock from which the core makes no forward progress.

The impact is an availability-only denial of service (permanent hang), reachable from an external or removable UART peer. Exploitation is gated by configuration: the error interrupt is off by default and no in-tree subsystem enables it, so only applications that explicitly call uartirqerrenable() on a PL011-based, interrupt-driven port are affected. The fix makes pl011isr() acknowledge the pending error bits via uart->icr, breaking the loop, and additionally clears the latched RSR status in pl011errcheck().

An issue was discovered in Mbed TLS versions from 2.19.0 up to 3.6.5, Mbed TLS 4.0.0. Insufficient protection of serialized SSL context or session structures allows an attacker who can modify the serialized structures to induce memory corruption, leading to arbitrary code execution. This is caused by Incorrect Use of Privileged APIs.

In Arm ArmNN through 2026-03-27, an integer overflow in TensorShape::GetNumElements() in armnn/Tensor.cpp allows a crafted TFLite model file to bypass buffer size validation and trigger a heap-based buffer over-read during model optimization. The overflow occurs when multiplying tensor dimensions using 32-bit unsigned arithmetic without overflow detection, causing GetNumBytes() to return an understated allocation size. During Optimize()->InferOutputShapes(), the BatchToSpaceNdLayer reads beyond the allocated buffer.

Arm Whois 3.11 contains a buffer overflow vulnerability that allows local attackers to execute arbitrary code by overwriting the structured exception handler. Attackers can craft a malicious input file with a 672-byte offset to overwrite the nSEH and SEH pointers, enabling code execution through exception handler hijacking.

Arm Whois 3.11 contains a stack-based buffer overflow vulnerability that allows remote attackers to execute arbitrary code by supplying oversized input to the IP address or domain field. Attackers can craft malicious input exceeding 658 bytes with shellcode to overwrite the structured exception handler and gain command execution when the application processes the input.

Arm Whois 3.11 contains a buffer overflow vulnerability that allows local attackers to crash the application by supplying an oversized input string. Attackers can paste a malicious buffer of 700 bytes into the IP address or domain input field to trigger a denial of service condition.

An unprivileged context can trigger a data memory-dependent prefetch engine to fetch the contents of a privileged location and consume those contents as an address that is also dereferenced.

Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in Arm Ltd Bifrost GPU Userspace Driver, Arm Ltd Valhall GPU Userspace Driver, Arm Ltd Arm 5th Gen GPU Architecture Userspace Driver allows a non-privileged user process to perform valid GPU processing operations, including via WebGL or WebGPU, to access outside of buffer bounds.This issue affects Bifrost GPU Userspace Driver: from r18p0 through r49p3, from r50p0 through r51p0; Valhall GPU Userspace Driver: from r28p0 through r49p3, from r50p0 through r54p0; Arm 5th Gen GPU Architecture Userspace Driver: from r41p0 through r49p3, from r50p0 through r54p0.

Use After Free vulnerability in Arm Ltd Bifrost GPU Kernel Driver, Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user process to perform valid GPU memory processing operations to gain access to already freed memory.This issue affects Bifrost GPU Kernel Driver: from r41p0 through r49p4, from r50p0 through r51p0; Valhall GPU Kernel Driver: from r41p0 through r49p4, from r50p0 through r54p0; Arm 5th Gen GPU Architecture Kernel Driver: from r41p0 through r49p4, from r50p0 through r54p0.

Use After Free vulnerability in Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user process to perform improper GPU memory processing operations to gain access to already freed memory.This issue affects Valhall GPU Kernel Driver: from r53p0 through r54p1; Arm 5th Gen GPU Architecture Kernel Driver: from r53p0 through r54p1.

Use After Free vulnerability in Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user process to perform improper GPU processing operations to gain access to already freed memory.This issue affects Valhall GPU Kernel Driver: from r53p0 through r54p1; Arm 5th Gen GPU Architecture Kernel Driver: from r53p0 through r54p1.

Uncontrolled Search Path Element in Arm Development Studio before 2025 may allow an attacker to perform a DLL hijacking attack. Successful exploitation could lead to local arbitrary code execution in the context of the user running Arm Development Studio.

Mbed TLS before 2.28.10 and 3.x before 3.6.3, on the client side, accepts servers that have trusted certificates for arbitrary hostnames unless the TLS client application calls mbedtlssslsethostname.

Mbed TLS before 2.28.10 and 3.x before 3.6.3, in some cases of failed memory allocation or hardware errors, uses uninitialized stack memory to compose the TLS Finished message, potentially leading to authentication bypasses such as replays.

Arm Bifrost and Valhall GPU kernel drivers contain a use-after-free vulnerability that allows a local, non-privileged user to make improper GPU memory processing operations to gain access to already freed memory.

Integer Overflow vulnerability in Mbed TLS 2.x before 2.28.7 and 3.x before 3.5.2 allows attackers to cause a denial of service (DoS) via mbedtlsx509setextension().

An issue was discovered in Mbed TLS 2.x before 2.28.7 and 3.x before 3.5.2. There was a timing side channel in RSA private operations.

During the secure boot, bl2 (the second stage of the bootloader) loops over images defined in the table “bl2memparamsdescs”. For each image, the bl2 reads the image length and destination from the image’s certificate. Because of the way of reading from the image, which base on 32-bit unsigned integer value, it can result to an integer overflow. An attacker can bypass memory range restriction and write data out of buffer bounds, which could result in bypass of secure boot.

Affected git version from c2f286820471ed276c57e603762bd831873e5a17 until (not