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

(5th Sep 2025)

Official Published: 09/01/2025

Preface: The Real-time Transport Protocol (RTP) is an application-layer protocol, typically used over UDP, that facilitates the real-time transmission of media like audio and video over IP networks. While not a component of the modem’s RF (Radio Frequency) system itself, which handles the wireless signal, RTP works with 5G modem-RF systems by providing the actual media data for real-time applications like Voice over LTE (VoLTE) and 5G voice.

Background: RTP works with 5G modem-RF systems by providing the actual media data for real-time applications like Voice over LTE (VoLTE) and 5G voice.

“RTP NALU” refers to the encapsulation of Network Abstract Layer Unit (NALU) into Real-time Transport Protocol (RTP) packets, which is commonly used in H.264 video streaming to transmit data in real-time. NALU is a data unit in H.264 video compression, and RTP is used to encapsulate the NALU so that it can be transmitted over the network and reconstructed at the receiver side.

Vulnerability details: Improper Restriction of Operations within the Bounds of a Memory Buffer in Data Network Stack & Connectivity.

Description: Memory corruption when the UE receives an RTP packet from the network, during the reassembly of NALUs.

Technology Area: Data Network Stack & Connectivity.

Vulnerability Type: CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer.

Why the 5G Modem-RF System Is Involved?

• The modem firmware handles real-time media transport, including RTP for VoLTE and 5G voice.
• RTP/NALU reassembly is part of the low-level packet processing pipeline in the modem.
• Since this is firmware-level code, it uses manual memory management (C/C++).
• The vulnerability allows attackers to send malformed RTP packets that overflow the buffer, leading to remote code execution at the kernel level.

Official announcement: Please see the link for details –

https://docs.qualcomm.com/product/publicresources/securitybulletin/september-2025-bulletin.html

Preface: Ansible Automation Platform is a broader enterprise automation platform designed to manage and automate various IT operations, including infrastructure, cloud, networking, and security. While it can be used for automating web server deployments and configurations. Besides, web hosting service providers can and often do use the Ansible Automation Platform for automating various tasks related to web hosting and infrastructure management.

Background: In Ansible, Jinja2 templating is widely used to dynamically render variables, expressions, and logic in playbooks, templates, and even hooks (like webhooks or event triggers in EDA).

You can use Jinja2 in:

•       Playbooks: For dynamic task names, conditions, and variables.

•       Templates: To generate configuration files.

•       Hooks or Webhooks: Especially in EDA, where incoming payloads can be parsed and matched using Jinja2 expressions.

When a POST request is sent to http[:][//]<EDA_HOST>[:]5000/alert with the payload:

•       The EDA controller receives the event.

•       It evaluates the condition using Jinja2.

•       If matched, it runs the playbook respond_to_critical_alert[.]yml.

Vulnerability details: A flaw was found in the EDA component of the Ansible Automation Platform, where user-supplied Git branch or refspec values are evaluated as Jinja2 templates. This vulnerability allows authenticated users to inject expressions that execute commands or access sensitive files on the EDA worker. In OpenShift, it can lead to service account token theft.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2025-49521

Preface: As of January 2025, Android holds a global market share of 72.15%, which is a big jump from just 12% back in 2010.

Background: The AccountTypePreferenceLoader is a class within the Android Settings app. It is responsible for loading and displaying account preferences, which include settings related to authenticator apps. This class plays a crucial role in managing user accounts and preferences on Android devices.

For example, when you add a new email account or a social media account to your Android device, the AccountTypePreferenceLoader ensures that the specific settings for that account type are properly loaded and displayed in the Settings app. This makes it easier for users to manage their accounts and customize their preferences.

Vulnerability details: AccountTypePreferenceLoader.java, there is a possible way to retrieve protected files from the Settings app due to a confused deputy. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

Official announcement: For more details, please refer to the following link – https://source.android.com/docs/security/bulletin/2025-02-01

Preface: NVIDIA® offers a wide range of Network Operating Systems (NOS), from the homegrown Ethernet Operating System, NVIDIA Mellanox Onyx™, to native Linux operating systems, NVIDIA Cumulus Linux, and a variety of vendor specific options.

Background: NVIDIA® MLNX-OS® operating system, enables the management and configuration of NVIDIA’s InfiniBand switch system platforms.

NVIDIA MLNX-OS®, an InfiniBand switch operating system for high-performance data centers, enables you to build networks that scale to thousands of compute and storage nodes, while also providing monitoring and provisioning capabilities.

Vulnerability details: CVE-2024-0101 – NVIDIA Mellanox OS, ONYX, Skyway, MetroX-2 and MetroX-3 XC contain a vulnerability in ipfilter, where improper ipfilter definitions could enable an attacker to cause a failure by attacking the switch. A successful exploit of this vulnerability might lead to denial of service.

Ref: A design flaw emerged about twenty-three years ago. , could it be related to this design weakness?

IPFilter caches the decision to forward or drop a fragment and applies this decision to other IP fragments with the same IP id. Even if the fragment is an “initial” fragment (a fragment with fragment offset 0) that may contain a TCP or UDP header, it will be evaluated against the decision cache.Therefore, an attacker could create a cache of “allow” decisions in IPFilter rules and then successfully bypass the rule set and pass fragments with arbitrary UDP or TCP headers through the device where IPFilter is installed.

Official announcement: Please refer to the official announcement for details – https://nvidia.custhelp.com/app/answers/detail/a_id/5559

Preface: The use of previously freed memory can have any number of adverse consequences – ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. They are common coding problems that can lead to vulnerabilities and affect stability.

Background: Why MTE? Memory safety bugs, which are errors in handling memory in native programming languages, are common code issues. They lead to security vulnerabilities as well as stability problems.Armv9 introduced the Arm Memory Tagging Extension (MTE), a hardware extension that allows you to catch use-after-free and buffer-overflow bugs in your native code.

Technical details: In December 2023, a research paper called ‘Sticky Tags: Efficient and Deterministic Spatial Memory Error Mitigation using Persistent Memory Tags’ was published by academics from VUSec Group, Vrije Universiteit Amsterdam. The paper demonstrates how speculative probing can potentially be used to determine Arm Memory Tagging Extension (MTE) allocation tags and explores alternative solutions to Arm MTE.

Official announcement: Please refer to the link for details – https://developer.arm.com/Arm%20Security%20Center/Arm%20Memory%20Tagging%20Extension