Revision Date : 2025-Dec-17

Preface: AMD removed “Arm” from “Arm Trusted Firmware” (TF-A) references in their documentation (like for their EPYC/ Ryzen CPUs) to signify that while it’s based on Arm’s open standard, their implementation is tailored for AMD hardware, making it AMD’s own secure boot/firmware solution, not just Arm’s code, promoting clearer branding and ownership for their specific silicon, even though it adheres to Arm’s secure architecture principles.

Background: General-purpose Versal™ adaptive SoCs combine programmable logic with embedded Arm® application and real-time CPU cores, a programmable network on chip, high-speed serial transceivers, programmable I/O, and a broad offering of hard IP.

As various operating systems from various different vendors can be present in an ARM system, performing power control requires a method of collaboration. Considering operation in Non-secure state, if a supervisory system that is managing power, whether it is executing at the OS level (EL1) or at hypervisor level (EL2), wants to enter an idle state, power up or power down a core, or reset or shut down the system, supervisory systems at other Exception levels will need to react to the power state change request.

“Secure” (as a flag/designation): This refers to the privilege level the request claims to have been initiated from. When a request, like a Power State Coordination Interface (PSCI) command, is marked as “secure,” it is asking to be treated as though it originated from the trusted Secure World, with full access rights to all system resources.

“Processor’s actual security state”: This refers to the physical, hardware-enforced execution state the CPU is currently operating in (either Non-Secure World or Secure World). The physical state determines which memory regions and peripherals the code can genuinely access.

Vulnerability details: The Secure Flag passed to VersalTM Adaptive SoC’s Trusted Firmware for Cortex®-A processors (TF-A) for Arm’s Power State Coordination Interface (PSCI) commands were incorrectly set to secure instead of using the processor’s actual security state. This would allow the PSCI requests to appear they were from processors in the secure state instead of the non-secure state.

The vulnerability affects Versal™ Adaptive SoC’s Arm® Trusted Firmware (TF-A) for Cortex-A processors.

Root cause: The Secure Flag passed to PSCI (Power State Coordination Interface) commands was incorrectly set to secure instead of reflecting the processor’s actual security state.

Impact: This misconfiguration allows PSCI requests from a non-secure processor to appear as if they originate from a secure state, potentially enabling unauthorized access or manipulation of secure resources.

Severity: CVSS v4.0 score is 1.0 (Low), but it compromises the integrity of the security model.

Official announcement: Please refer to the link for details.

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

CVE-2025-48633- Improper use of Binder identity manipulation in system code (18th Dec 2025)

Official announcement:  December 1, 2025 | Updated December 4, 2025

Preface: The improper use of Binder identity manipulation in Android system code refers to a class of security vulnerabilities where a malicious application or process can spoof its identity (specifically its User ID and Process ID) when communicating with a trusted system service via the Binder Inter-Process Communication (IPC) mechanism. This deception can allow a lower-privileged application to bypass security checks and execute sensitive operations with the privileges of a legitimate, trusted system process

Before the remedy – The code iterated through each user profile and created a context for that user. It then called AccountManager.getAccounts() for that specific user context. This means the check was per-user, and the caller only saw accounts for the user context it created. However, because the code temporarily cleared the Binder identity (Binder.clearCallingIdentity()), it was operating with system-level privileges during that loop. If misused, this could allow a component to access accounts across users, which is a privilege escalation risk.

What was the vulnerability?

The issue was in the Android system code that checked whether any accounts existed on the device. Please refer to the attached diagram for details.

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

My originally scheduled for release on December 17, 2025, it was released ahead of schedule!

Preface: PCIe is one protocol used to transfer data across the SerDes. Different protocols can be used to transfer data across the SerDes.

SerDes (Serializer/Deserializer) in PCIe Gen 5 and Gen 2 are critical physical layer components that handle high-speed data conversion, but Gen 5 operates at a massive 32 GT/s per lane, doubling Gen 2’s 5 GT/s, requiring advanced signal integrity (like DSP, error correction) and sophisticated retimers to manage vastly higher frequencies (32 GHz vs. 5 GHz), while maintaining backward compatibility for seamless integration, crucial for modern AI/ML and data-intensive applications

Background: Recent AMD advisories (CVE-2025-9612/9613/9614) highlight vulnerabilities in PCIe Integrity and Data Encryption (IDE) and IOCTL-based SERDES control. These flaws allow attackers with low-level or physical access to manipulate PCIe traffic or exploit driver logic, potentially leading to:

• Data Integrity Violations
• Privilege Escalation
• Denial of Service (DoS)

Google’s Ironwood TPU architecture uses PCIe Gen5 (host) and Gen2 (gBMC) links, both relying on SERDES for high-speed signaling. If TPU drivers expose IOCTL interfaces for SERDES configuration without strict validation, similar risks apply:

• Direct Hardware Access: IOCTLs can alter PLL settings, lane equalization, and data rates.
• Privilege Escalation: Weak access control could let non-root processes manipulate SERDES.
• Kernel Attack Surface: Complex IOCTL handlers may enable buffer overflow or arbitrary code execution.

Impact on Cloud TPU Deployments: Ironwood’s scale—9,216 chips per pod, 1.77 PB shared memory, and 9.6 Tb/s interconnect bandwidth—amplifies the consequences of link instability or compromised isolation. Multi-tenant environments increase exposure to insider or advanced persistent threats.

Recommended Mitigations

Restrict IOCTL Access: Enforce root-only privileges for SERDES configuration commands.

Implement capability checks for sensitive operations (e.g., SERDES_SET_DATA_RATE).

Validate Input Parameters: Ensure strict bounds on PLL, lane equalization, and data rate settings.

Apply PCIe IDE Erratum #1 Guidance: Update firmware to address IDE vulnerabilities per PCI-SIG recommendations.

Enable Hardware Security Features: Use IOMMU and Zero-Trust principles for PCIe endpoints.

Continuous Monitoring: Deploy anomaly detection for PCIe link training and SERDES state changes.

– End of article –

My originally scheduled for release on December 15, 2025, it was released ahead of schedule!

Stable Channel Update for Desktop – Wednesday, December 10, 2025

Preface: About Google browser (The Storage Architecture): A Database, Not Just a Flat File . Chrome stores login data, including usernames, the website URL, and the encrypted password, in a local SQLite database file named Login Data. This is a structured database, not just a raw file opened and read with basic I/O or mmap() for the specific password fields.

Background: Chrome browser temporarily holds decrypted passwords in memory for a short duration when the user is actively logged in and using the browser. This design choice is fundamental to the “autofill” functionality and allows for a seamless login experience, but it introduces a specific, nuanced security consideration.

When a user visits a website and Chrome needs to autofill credentials, or when the user views their passwords in the settings, the necessary data is retrieved from the encrypted database and decrypted in memory only for that specific, immediate use.

Important: The Necessity of In-Memory Decryption

The core of your query lies in the operational phase. When you visit a website that requires a login, Chrome must retrieve the stored, encrypted password, decrypt it using the relevant OS-level key, and then inject the actual plaintext password into the login form for the autofill feature to work.

Vulnerability details: (CVE-2025-14372) Use after free in Password Manager.

Key points related to this design flaw:

• Structured Storage: Chrome uses a SQLite database (Login Data) for credentials, not a flat file. This means any memory-related flaw could impact query execution rather than raw file reads.
• Multi-Layered Decryption: Chrome leverages OS-level APIs (e.g., DPAPI on Windows, Keychain on macOS) for decrypting passwords, so the vulnerability likely affects intermediate steps rather than the final decryption logic.
• SQLite Vulnerability: The aggregate term overflow issue is real and could lead to memory corruption if Chrome’s query patterns trigger it.

Official announcement: Please refer to the link for details –

https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop_10.html

NVD Last Modified: 12/08/2025

Preface: urllib3 is extremely popular and foundational in the Python ecosystem, acting as a core dependency for many top libraries like requests, pip, and kubernetes, though it’s often used indirectly through the more user-friendly requests library for general tasks. It’s a robust, low-level HTTP client known for features like connection pooling and thread safety, making it a cornerstone for complex applications and other tools.

Background:

kubectl and client-go (Go-based)

These are the default and most widely used tools for Kubernetes:

• kubectl is the official CLI tool for cluster management.
• client-go is the official Go client library, used by Kubernetes controllers, operators, and most production-grade tools.
• Almost all core Kubernetes components and many third-party operators are written in Go.

Ref: Kubernetes (via kubectl and client-go) doesn’t use urllib3—it’s written in Go and uses its own HTTP stack. So the Go-based Kubernetes API client is unaffected by this Python-specific issue.

Python-based Kubernetes clients

These are popular in data science, automation, and DevOps scripting, but far less common for building core Kubernetes components. They’re widely used in:

• CI/CD pipelines
• Custom scripts for cluster operations
• Machine learning workflows (where Python dominates)

Ref: Python-based Kubernetes clients (like the one in your example) do rely on urllib3 internally through the requests library or similar. If you’re using these clients, you must upgrade urllib3 to a patched version (≥ 2.6.0 once available).

Vulnerability details: (CVE-2025-66471) urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3’s streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.

Official announcement: Please refer to the link for details –

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