Preface: Semi-Persistent Scheduling (SPS) is used in LTE and 5G networks to reduce control channel overhead for applications requiring persistent radio resource allocations, such as VoIP and VoLTE . The memory usage for SPS on Android devices can vary based on several factors, including the specific implementation and the network conditions.

A method and apparatus for determining validity of a semi-persistent scheduling (SPS) resource across multiple cells in a wireless communication system is provided. A user equipment (UE) receives a SPS resource configuration including time information related to validity of the SPS resource configuration from a network, and determines whether the SPS resource configuration is valid or not according to the time information.

Background: Semi-Persistent Scheduling (SPS) Workflow

1. The RF module in the Snapdragon chip receives the SPS resource configuration from the network. This configuration includes time information related to the validity of the SPS resource.
2. The Physical Layer (PHY) processes the received configuration to determine its validity based on the time information provided.
3. If the configuration is valid, the Medium Access Control (MAC) layer handles the allocation of radio resources for multiple consecutive Transmission Time Intervals (TTIs). This reduces the need for frequent scheduling decisions and signaling overhead.
4. The MAC layer coordinates with the Radio Link Control (RLC) layer to manage data transmission using the allocated resources. The RLC layer ensures data integrity and proper sequencing.
5. The Digital Signal Processor (DSP) and Application Processor within the Snapdragon chip are responsible for executing the scheduling algorithms and managing the data flow.The configuration and scheduling information are stored in the shared memory accessible by both the DSP and the application processor.

Vulnerability details: Out-of-bounds Write in SPS Applications. Memory corruption while reading secure file. This is a type of memory access error that occurs when a program writes data from a memory address outside of the bounds of a buffer. This can result in the program writing data that does not belong to it, which can cause crashes, incorrect behavior, or even security vulnerabilities.

Official announcement: For details, please refer to the link –https://nvd.nist.gov/vuln/detail/cve-2024-49835

(7^th May 2025)

Last updated: 2 May 2025 (official)

Preface: An ioctl interface is a single system call by which userspace may communicate with device drivers. Requests on a device driver are vectored with respect to this ioctl system call, typically by a handle to the device and a request number.

Background: The Arm Mali GPU, when installed on an Android phone, works alongside the CPU rather than replacing it. The Mali GPU is specifically designed for handling graphics processing tasks, such as rendering images, animations, and videos, which helps to offload these tasks from the CPU. This allows the CPU to focus on other computational tasks, improving overall device performance and efficiency.

The Mali GPU itself does not have an embedded CPU; it is a separate component that works in conjunction with the device’s main CPU. This collaboration between the GPU and CPU ensures that graphics-intensive applications, like games and videos, run smoothly while maintaining efficient power usage.

Vulnerability details: 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 processing operations to gain access to already freed memory.

Impact: This issue affects Bifrost GPU Kernel Driver: from r8p0 through r49p3, from r50p0 through r51p0; Valhall GPU Kernel Driver: from r19p0 through r49p3, from r50p0 through r53p0; Arm 5th Gen GPU Architecture Kernel Driver: from r41p0 through r49p3, from r50p0 through r53p0.

Official announcement: Please see the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2025-0427

https://developer.arm.com/documentation/110465/latest

Official release posted: 2^nd May 2025

Since the manufacturer did not provide a detailed description, is the situation discovered by the manufacturer similar to this article details?

Preface:

Nvidia is a major player in the GPU market, known for its high-performance graphics cards used in gaming, professional visualization, data centers, and AI applications.

Imagination Technologies specializes in providing GPU processor solutions for graphics and AI vision applications. They focus on mobile devices, automotive, and embedded systems.

Background: All PowerVR GPUs are based on unique Tile Based Deferred Rendering (TBDR) architecture; the only true deferred rendering GPU architecture in the world.  True deferred rendering GPU architecture, specifically Tile-Based Deferred Rendering (TBDR), is a unique approach used by PowerVR GPUs.

Tile-Based Deferred Rendering (TBDR)

– Tile-Based Rendering: The screen is divided into small tiles, and each tile is processed individually. This allows the GPU to store data like color and depth buffers in internal memory, reducing the need for frequent access to system memory. This results in lower energy consumption and higher performance.

– Deferred Rendering: This technique defers texturing and shading operations until the visibility of each pixel in the tile is determined. Only the pixels that will be visible to the user consume processing resources, which enhances efficiency.

Vulnerability details: Software installed and run as a non-privileged user may conduct ptrace system calls to issue writes to GPU origin read only memory.

Resolution: The DDK Kernel module has been updated to address this  improper use of ptrace system call to prevent write requests to read-only memory.

Official announcement: Please see the link for details –

https://www.imaginationtech.com/gpu-driver-vulnerabilities