| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the NAS Authentication Request message decoding procedure, a missing lower bound check causes an infinite loop, leading to Denial of Service. |
| Insufficient validation of length fields in the GNSS firmware loader can result in kernel‑memory corruption. |
| Integer overflow in NPU driver parameter processing due to insufficient bounds checking. |
| Coder 2.28.0 before 2.29.22, 2.30.0 before 2.34.13, 2.35.0 before 2.35.10, 2.36.0 before 2.36.8, 2.37.0 before 2.37.5, and 2.38.0 before 2.38.1 contains a path traversal vulnerability in the AI Gateway passthrough router, which forwards percent-encoded dot segments upstream without rejecting them. Authenticated users can send paths such as %2e%2e or ..%2F under allowlisted prefixes to reach unintended provider endpoints using the deployment's centrally managed provider key. |
| Incorrect handling of unauthenticated downlink RRC Setup messages can cause the baseband to crash |
| Shopify App is a Rails engine for building Shopify applications. From 22.1.0 until 23.0.3, `token-exchange` authenticated controllers can expose a request-derived `shop` context instead of the identity from a verified Shopify ID token or active Shopify session. `current_shopify_domain` can resolve to the sanitized `shop` query parameter, so a request authenticated for one `shop` can cause application code to treat a different requested `shop` as current. Affected applications use `shopify_app` `token-exchange` authentication, accept authenticated requests with a `shop` query parameter, and rely on `current_shopify_domain` or `params[:shop]` for authorization, tenant lookup, stored access-token selection or `shop`-scoped data access. An attacker with a valid Shopify session token for one `shop` can supply another `shop` in that parameter and potentially obtain unauthorized application data or perform `shop`-scoped actions, depending on the application's authorization model. This issue is fixed in version 23.0.3. |
| In the Samsung Exynos ENN NeuralNetworks HAL, improper input validation during request processing can cause memory corruption and lead to a denial of service condition. |
| In the Samsung Exynos H-Arx DRM plugin, improper input validation during buffer operations can cause memory corruption, potentially leading to denial of service or privilege escalation. |
| A double free vulnerability in NPU driver due to improper pointer management (940) |
| Out of bound access in PPC due to race condition in global variable access |
| In the NR RRC component, improper handling of messages before authentication triggers a data abort, which leads to a denial‑of‑service condition. |
| In the NAS message handler, improper validation of the length field in NAS message causes memory corruption |
| Incorrect handling of SIP packets leads to baseband crashes |
| In G4KLX DStarGateway and F4FXL DStarGateway before 7b75de6, dstarCallsignToAPRS in APRSUtils.cpp has an integer underflow via an empty RS-MS1A sender field. |
| In IMS stack, improper handling of SIP packets leads to Incorrect_Access_Control vulnerability |
| Incorrect handling of SDP payload leads to a Denial of Service |
| In the Exynos NPU driver, improper validation of user input in the ioctl handler can lead to an out-of-bounds write, which causes a denial of service |
| In the Linux kernel, the following vulnerability has been resolved:
tracing/syscalls: Use copy_from_user for the faultable syscall buffer
syscall_copy_user_array() copies the buffer argument of faultable
syscalls (write, pwrite64, ...) with __copy_from_user(), which skips
access_ok(). Use copy_from_user() instead so a non-user address is
rejected and the entry is recorded as faulted.
It could be a security concern for machines that trust perf a bit too
much. |
| In the Linux kernel, the following vulnerability has been resolved:
pid_namespace: prevent TIF_NOTIFY_SIGNAL from interrupting the reaper
Since commit 7fea700e04bd ("zap_pid_ns_processes: clear
TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING") zap_pid_ns_processes()
clears TIF_NOTIFY_SIGNAL before every kernel_wait4() call. Otherwise
kernel_wait4() doesn't sleep and returns -ERESTARTSYS if
signal_pending() is true and the reaper busy-waits.
But clearing TIF_NOTIFY_SIGNAL doesn't fix it. It can get raised again.
For example, klp_send_signals() sets it raw against any task that hasn't
transitioned yet. And it keeps sending it until the livepatch finishes.
The sleep loop waiting for pid_allocated to drop has the same problem
and it doesn't even clear anything. So a schedule() in
TASK_INTERRUPTIBLE returns immediately.
Use a no_notify_signal guard. signal_pending() will ignore
TIF_NOTIFY_SIGNAL and the pid namespace reaper sleeps until a child
exits or free_pid() wakes it. |
| In the Exynos modem's IMS stack, improper handling of SDP payload leads to a Denial of Service |
