Preface: 5G Timing Advance (TA) invocation is a mechanism where the base station (gNB) instructs user equipment (UE) to advance its uplink transmission timing to compensate for signal propagation delays. This synchronization ensures that signals from UEs at different distances arrive at the gNB within the same time slot, preventing interference.

Background: In the 5G NR (New Radio) 4-step RACH (Random Access Channel) procedure, TA (Timing Advance) is a critical parameter provided within Msg2, also known as the Random Access Response (RAR). For NR Random Access Response (Msg2):

RAR payload = exactly 7 bytes (56 bits)

• 12-bit Timing Advance Command
• 27-bit Uplink Grant
• 16-bit Temporary C-RNTI

Plus 1 byte MAC subheader (RAPID)

Total bytes read by UE MAC = 8 bytes per RAR

This is fixed by spec. There is no variable-length TA field in Msg2. The TA length is always 12 bits in RAR

Vulnerability details: CVE-2025-47373. This is a classic case of Type Confusion or an Improper Bounds Check within the firmware’s protocol stack. In the context of Qualcomm modem components (like those in the Snapdragon 8 Gen 3), when the firmware confuses these two differently-sized TA fields, it creates a significant security vulnerability.

Why this constitutes a CVE Vulnerability? If the firmware reuses the same handler or buffer without validating the context (RAR vs. MAC CE), it leads to:

• Integer Overflow/Truncation: Forcing a 12-bit RAR TA (up to 3846) into a logic path or variable expected to be 6-bit (0-63) causes data corruption in the accumulator.
• Buffer Overflow: If the 12-bit data is written into a memory structure (like a bit-field or a small array) designed only for 6-bit values, it will overwrite adjacent memory.
• Out-of-bounds (OOB) Write: In the Snapdragon scheduling logic, TA values are often used to calculate offsets in timing tables. An unvalidated 12-bit value can cause a pointer to point outside the intended buffer.

Official announcement: Please refer to the link for details –

https://docs.qualcomm.com/securitybulletin/march-2026-bulletin.html

Preface: Qualcomm’s pVM (Protected Virtual Machine) refers to the secure, isolated virtual machine environment supported by the Gunyah hypervisor. PVMFW (pVM Firmware) is the specific binary code (pvmfw.bin) executed first within a pVM to bootstrap secure boot, validate the environment, and derive unique secrets for that specific guest. In short, pVM is the container, while pvmfw is the secure bootloader for that container.

Background: To “read the memory” of a Microdroid pVM from the host, you cannot bypass the hypervisor’s isolation. Instead, you must use Binder RPC (over virtio-vsock) to request data from a service running inside the pVM. Qualcomm’s sensitive keys (such as encryption keys and passwords) are typically stored in its Trusted Execution Environment (TEE) or a dedicated RPMB (Replay Protected Memory Block) partition. The RPMB is a hardware partition on the storage chip. It is managed and “owned” by the TEE (Secure World), while the EL1 Kernel and EL2 Hypervisor serve only as communication bridges for data transit.

Remark: Refer to the attached diagram, the AIDL code design follows the standard RPC (Remote Procedure Call) pattern. The fundamental “design limitation” here is that the Guest (Microdroid) must trust the Hypervisor (EL2) to enforce the boundaries.

If CVE-2025-47378 is present:

1.Your readData function is “truthful” and only returns 1024 bytes.

2.However, the Host app uses the Hypervisor flaw to read the other memory in your pVM where your actual secrets (keys, sensitive processing) might be stored.

Vulnerability details: Cryptographic Issue when a shared VM reference allows HLOS to boot loader and access cert chain.

Official announcement: Please refer to the link for details – https://docs.qualcomm.com/product/publicresources/securitybulletin/march-2026-bulletin.html

Preface: In iOS development, CVE-2026-20674 relates to a security vulnerability where sensitive information could potentially be accessed through Accessibility services while the device is locked.

Background: UIApplication.shared.isProtectedDataAvailable

impacts the iOS lockscreen because it directly reflects whether user-encrypted data (Keychain, files) is accessible based on the device’s lock status. When locked, this returns false, causing apps launched in the background (e.g., via notifications or prewarming) to fail to read sensitive data, potentially leading to incorrect states or user logouts. 

Key reasons for the impact:

• Encrypted Data Lock: Files protected with NSDataWritingFileProtectionComplete or NSDataWritingFileProtectionCompleteUnlessOpen are inaccessible until the user unlocks the device.
• Background Launch Failures: If an app is launched in the background (e.g., notification, Live Activity) while the screen is locked, attempts to read credentials from the Keychain or files will return nil, potentially causing the user to be signed out.
• State Corruption: Initializing data or reading from UserDefaults while the device is locked might read empty/default values, allowing the app to incorrectly overwrite existing secure data. 

Vulnerability details: A privacy issue was addressed by removing sensitive data. This issue is fixed in iOS 26.3 and iPadOS 26.3. An attacker with physical access to a locked device may be able to view sensitive user information.

Official announcement: Please refer to the link for details.

https://nvd.nist.gov/vuln/detail/CVE-2026-20674

Preface: SPD (Serial Presence Detect) metadata is not used by CPU or GPU manufacturers for the processors themselves, but it is an industry-standard requirement for the memory modules (RAM) that these processors depend on.

Background: DIMM Serial Presence Detect (SPD) protects Ring 0 by ensuring the BIOS/UEFI correctly identifies memory characteristics (timings, voltage, size) during POST. By providing accurate data, it prevents misconfiguration that could lead to memory corruption, stability issues, or exploitation of low-level system management mode (SMM). Properly locked SPD protects against malicious tampering that could bypass memory protections.

Ref: AMD EPYC “Genoa” is the codename for AMD’s 4th generation server processors, built on the Zen 4 microarchitecture and using a 5nm manufacturing process. Compared to its predecessor, Milan, Genoa increases the maximum core count to 96 and is the first to introduce DDR5 memory and PCIe 5.0 support, targeting the data center, cloud computing, and high-performance computing (HPC) markets.

Vulnerability details: CVE-2024-36354 Improper input validation for DIMM serial presence detect (SPD) metadata could allow an attacker with physical access, ring0 access on a system with a non-compliant DIMM, or control over the Root of Trust for BIOS update, to bypass SMM isolation potentially resulting in arbitrary code execution at the SMM level.

Additional: This is not a substitute for the vendor fix. If the vulnerable code is inside proprietary AGESA/PI binaries, you still need the patched package. So the core issue is validation logic inside the firmware boot flow handling SPD data.

Official announcement: Please refer to the link for more details –

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3014.html