Preface: The com.android[.]providers[.]telephony and com[.]android[.]phone packages are not similar in function; they serve different and distinct purposes in the Android telephony system.

This package (com[.]android[.]providers[.]telephony) is a content provider that manages and provides access to telephony-related data. 

• Database manager: It contains data related to phone operations, including the history and content of SMS and MMS messages, call logs, and the list of Access Point Names (APNs) used for mobile data connections.
• Data access: Other apps must request permission to access this package’s database to read or write call logs, SMS, and other telephony data.

Background: The Telephony provider and its associated classes like com[.]android[.]providers[.]telephony[.]PushMessageProvider are common in Android smartphones as they are core components of the operating system responsible for managing SMS and MMS messages. com[.]android[.]providers[.]telephony[.]PushShopProvider and com[.]android[.]providers[.]telephony[.]ServiceNumberProvider are also standard components for managing push messages and service numbers, respectively.

Vulnerability details:

The vulnerability allows any application installed on the device to read SMS/MMS data and metadata from the system-provided Telephony provider without permission, user interaction, or consent. The user is also not notified that SMS data is being accessed. This could lead to sensitive information disclosure and could effectively break the security provided by SMS-based Multi-Factor Authentication (MFA) checks. The root cause is a combination of missing permissions for write operations in several content providers (com[.]android[.]providers[.]telephony[.]PushMessageProvider, com[.]android[.]providers[.]telephony[.]PushShopProvider, com[.]android[.]providers[.]telephony[.]ServiceNumberProvider), and a blind SQL injection in the update method of those providers.

Ref: The issue stems from two main problems in the content providers:

Missing write permissions in several exported content providers:

com[.]android[.]providers[.]telephony[.]PushMessageProvider

com[.]android[.]providers[.]telephony[.]PushShopProvider

com[.]android[.]providers[.]telephony[.]ServiceNumberProvider

A blind SQL injection vulnerability in the update() method of these providers:

The where clause in SQL queries is passed unsanitized, allowing attackers to inject arbitrary SQL commands.

Official announcement: Please see the link for details –

https://www.tenable.com/cve/CVE-2025-10184

Preface: DDR5 memory has two independent 32-bit sub-channels per DIMM, while DDR4 uses a single 64-bit channel. There are many types of DDR5 DIMMs.

• UDIMM (Unbuffered DIMM): Commonly used in consumer-grade desktops and laptops, UDIMMs provide a balance of performance and cost-efficiency.
• RDIMM (Registered DIMM): Utilized in servers and workstations, RDIMMs include a register that buffers data, enhancing stability and allowing for larger memory capacities.
• SODIMM (Small Outline DIMM): Designed for laptops and compact devices, SODIMMs offer a smaller form factor without sacrificing performance.

Background: DRAM side-channel attacks exploit timing differencesand row buffer behavior in the memory subsystem — particularly row conflicts and row hits — to infer sensitive information. These behaviors are fundamental to how DRAM works, regardless of whether it’s UDIMM, RDIMM, or SODIMM.

What does vary between DIMM types is:

• Signal integrity and buffering (RDIMMs have registers that buffer commands)
• Capacity and scalability
• Latency and performance characteristics

However, the core vulnerability — the ability to observe timing differences due to row buffer behavior — exists across all types of DRAM. The attack feasibility may differ slightly due to architectural differences, but no DIMM type is inherently immune.

Researchers have provided AMD with a paper titled “Quo VADIS DDR5? Verifying Addressing of DRAM In Software.”

In this paper, the authors present an approach to verifying DRAM addressing functions from software using the DRAM row conflict side channel. The authors claim that the presented verification methodology provides a cheap and reliable alternative to verification using physical access and expensive measurement equipment such as oscilloscopes. They also demonstrate that they exploited the row conflict side channel as a covert channel and a website fingerprinting attack with a high success rate.

Security Focus: University Researchers discovered the previously unknown rank selection side channel and reverse engineer its function on two DDR4 and two DDR5 systems. These results enable novel DDR5 row-conflict side-channel attacks, which we demonstrated in two scenarios: a covert channel with 1.39 Mbit/s, and a website fingerprinting attack with an F1 score of 84 % on DDR4 and 74 % on DDR5. They conclude that as reverse-engineering of DRAM address functions remains relevant, our new verification methodology provides a cheap and reliable alternative to verification using expensive physical measurements.

Official announcement: Please see the link for details –

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

Preface: The researchers behind the related “ZenHammer” work found that using traditional timing side-channel methods for synchronization was less reliable on AMD Zen platforms compared to Intel CPUs. The Phoenix attack was designed to overcome these challenges using a “self-correcting” technique.

Background: Phoenix attack does not use XOR or similar software-level bit manipulation. Instead, it exploits physical properties of DRAM cells — flipping bits by repeatedly accessing adjacent rows (hammering), which causes electrical interference. The “Phoenix” attack, a system-level Rowhammer attack against DDR5 memory, requires monitoring timing to maintain synchronization with the memory’s refresh commands, which are essential for the attack’s success and for triggering bit flips despite mitigations like Targeted Row Refresh (TRR). The attack uses a “self-correcting” synchronization method that realigns the hammer pattern whenever a missed refresh is detected, allowing it to remain synchronized over long periods and bypass defenses that would otherwise prevent bit flips.

A CPU/GPU bit flip is an unintentional change of a digital bit’s value (from 0 to 1, or 1 to 0) within the Central Processing Unit (CPU) or Graphics Processing Unit (GPU). These errors can stem from hardware malfunctions, electromagnetic interference, cosmic rays, or manufacturing defects, potentially leading to incorrect calculations, data corruption, or system crashes. Modern processors often use techniques like Error Correcting Code (ECC) to detect and fix these errors, especially in high-assurance environments.

Vulnerability details: Researchers were able to use rowhammering techniques on DDR5 memory to obtain bitflips in order to escalate privileges.AMD believes this to be a memory issue. Susceptibility to rowhammer attacks varies based on the DRAM device, vendor, technology, and system settings. AMD recommends contacting your DRAM or system manufacturer to determine susceptibility.

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

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