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.
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.
Preface: Suppose you’re using cuML’s model persistence feature to load a serialized model from disk or a remote source. If the source is not trusted or validated, and the deserialization uses pickle or similar unsafe methods, it could execute arbitrary code.
The attached diagram demonstrates arbitrary code execution via pickle, which aligns with CVE-2025-33214 and likely CVE-2025-33213 if input validation is missing.
Background: NVTabular is a component of NVIDIA Merlin, an open source framework for building and deploying recommender systems and works with the other Merlin components including Merlin Models, HugeCTR and Merlin Systems to provide end-to-end acceleration of recommender systems on the GPU.
NVTabular requires Python version 3.7+. Additionally, GPU support requires:
CUDA version 11.0+
NVIDIA Pascal GPU or later (Compute Capability >=6.0)
NVIDIA driver 450.80.02+
Linux or WSL
When running NVTabular on the Criteo 1TB Click Logs Dataset using a single V100 32GB GPU, feature engineering and preprocessing was able to be completed in 13 minutes. Furthermore, when running NVTabular on a DGX-1 cluster with eight V100 GPUs, feature engineering and preprocessing was able to be completed within three minutes. Combined with HugeCTR, the dataset can be processed and a full model can be trained in only six minutes.
NVIDIA Merlin™ accelerates the entire pipeline, from ingesting and training to deploying GPU-accelerated recommender systems. Merlin NVTabular is a feature engineering and preprocessing library designed to effectively manipulate terabytes of recommender system datasets and significantly reduce data preparation time. It provides efficient feature transformations, preprocessing, and high-level abstraction that accelerates computation on GPUs using the RAPIDS™ cuDF library.
Vulnerability details:
CVE-2025-33214 – NVIDIA NVTabular for Linux contains a vulnerability in the Workflow component, where a user could cause a deserialization issue. A successful exploit of this vulnerability might lead to code execution, denial of service, information disclosure, and data tampering.
CVE-2025-33213 – NVIDIA Merlin Transformers4Rec for Linux contains a vulnerability in the Trainer component where a user may cause a deserialization issue. A successful exploit of this vulnerability may lead to code execution, denial of service, information disclosure, and data tampering.
Official announcement: Please refer to the following link for details-
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 –
Preface: The security concerns regarding data integrity in Peripheral Component Interconnect Express (PCIe) transactions are a critical aspect of modern computing, particularly in data centers, cloud environments, and automotive systems where sensitive information is routinely handled. Historically, PCIe interfaces were considered relatively secure due to their placement inside a server enclosure, but the rise of disaggregated systems, confidential computing, and sophisticated physical attacks has changed this perspective entirely. As an interconnect that links the CPU to various peripherals like GPUs, SSDs, and network adapters, any vulnerability can have far-reaching consequences, leading to data corruption, unauthorized access, or system compromise.
Background: AMD EPYC processors use an I/O Die (IOD) to manage all external interfaces, connecting to CPU Dies (CCDs) via high-speed Global Memory Interconnect (GMI) links and handling numerous DDR5 memory channels, PCIe Gen5, and CXL lanes, with SERDES (Serializer/Deserializer) technology underpinning these fast connections for massive bandwidth and low latency in data-intensive workloads, allowing for up to 12 memory channels and 128 PCIe lanes per socket in recent generations.
AMD SERDES technology significantly enhances the physical-layer data integrity and signal quality in PCIe transactions, but it is distinct from higher-level security features like encryption. SERDES technology is a foundational element that ensures reliable data transmission at extremely high speeds.
Affected Products and Mitigation:
From security point of view, it expect additional details from the PCIe SIG and plan to update this security notice as more information is available. At this time, AMD believes the following products may be impacted.
AMD EPYC™ 9005 Series Processors
AMD EPYC™ Embedded 9005 Series Processors
Ref: PCI-SIG (Peripheral Component Interconnect Special Interest Group) is the electronics industry consortium that defines and maintains the standards for PCI, PCI-X, and PCI Express (PCIe) computer buses, ensuring high-speed, interoperable connectivity for components like graphics cards, SSDs, and network adapters in computers and data centers. This non-profit group, with hundreds of member companies, develops specifications, promotes compliance, and fosters an open ecosystem for PCIe technology, allowing different manufacturers’ products to work together seamlessly.
Vulnerability details:
CVE-2025-9612 (non-AMD) : An issue was discovered in the PCI Express (PCIe) Integrity and Data Encryption (IDE) specification, where insufficient guidance on Transaction Layer Packet (TLP) ordering and tag uniqueness may allow encrypted packets to be replayed or reordered without detection. This can enable local or physical attackers on the PCIe bus to violate data integrity protections.
CVE-2025-9613 (non-AMD): A vulnerability was discovered in the PCI Express (PCIe) Integrity and Data Encryption (IDE) specification, where insufficient guidance on tag reuse after completion timeouts may allow multiple outstanding Non-Posted Requests to share the same tag. This tag aliasing condition can result in completions being delivered to the wrong security context, potentially compromising data integrity and confidentiality.
CVE-2025-9614 (non-AMD): An issue was discovered in the PCI Express (PCIe) Integrity and Data Encryption (IDE) specification, where insufficient guidance on re-keying and stream flushing during device rebinding may allow stale write transactions from a previous security context to be processed in a new one. This can lead to unintended data access across trusted domains, compromising confidentiality and integrity.
Official announcement: Please refer to the link for details –
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:
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 –
Preface: Triton Inference Server is an open source inference serving software that streamlines AI inferencing. Triton Inference Server enables teams to deploy any AI model from multiple deep learning and machine learning frameworks, including TensorRT, PyTorch, ONNX, OpenVINO, Python, RAPIDS FIL, and more.
Background: The NVIDIA Triton Inference Server natively supports gRPC as one of its primary communication protocols for the client API. Furthermore, gRPC can also be used for health checks, statistics, and model loading/unloading operations, not just inference requests. Inference requests arrive at the server via either HTTP/REST or GRPC or by the C API and are then routed to the appropriate per-model scheduler. Triton implements multiple scheduling and batching algorithms that can be configured on a model-by-model basis.
Triton major features:
Supports multiple deep learning frameworks
Supports multiple machine learning frameworks
Concurrent model execution
Dynamic batching
Sequence batching and implicit state management for stateful models
Provides Backend API that allows adding custom backends and pre/post processing operations
Model pipelines using Ensembling or Business Logic Scripting (BLS)
HTTP/REST and GRPC inference protocols based on the community developed KServe protocol
A C API and Java API allow Triton to link directly into your application for edge and other in-process use cases
Metrics indicating GPU utilization, server throughput, server latency, and more
Vulnerability details:
CVE-2025-33211 NVIDIA Triton Server for Linux contains a vulnerability where an attacker may cause an improper validation of specified quantity in input. A successful exploit of this vulnerability may lead to denial of service.
CVE-2025-33201 NVIDIA Triton Inference Server contains a vulnerability where an attacker may cause an improper check for unusual or exceptional conditions issue by sending extra large payloads. A successful exploit of this vulnerability may lead to denial of service.
Official announcement: Please refer to the link for details –
Preface: Coronal mass ejections (CMEs) impact Earth’s magnetic field, and their effects depend on the intensity and direction of the CME. Mild impacts can cause minor disturbances (such as beautiful auroras), while severe impacts can lead to serious consequences such as power grid failures, satellite damage, and radio outages. They can even trigger widespread technological disruptions, as seen in the Carrington Event of 1859. Scientists closely monitor these geomagnetic storms and use a G1-G5 scale to predict their impacts. The effects of geomagnetic storms are wide-ranging, encompassing almost everything from GPS to the internet, especially in vulnerable areas with dense power transmission lines.
Background: On December 4, 2025, the Sun did produce an M6-class solar flare from sunspot AR 4300, which launched a Coronal Mass Ejection (CME) likely directed at Earth, contributing to subsequent moderate geomagnetic storming and aurora displays around December 8-9, 2025. This event, combined with other flares from active regions like AR 4299, led to strong aurora alerts and impacts on satellites/radio.
Major earthquake strikes Japan’s north-east coast on 9th Dec 2025. The quake occurred at 23:15 (14:15 GMT) at a depth of 50km (31 miles), about 80km off the coast of the Aomori region.
Unproven causal relationship: While the idea that solar storms (CMEs) trigger earthquakes is popular, scientific consensus remains divided; major geological bodies like the USGS say there’s no proven link, but some research suggests statistically significant correlations where large solar events might precede earthquakes by influencing Earth’s magnetic field or triggering subterranean processes, though it’s not a direct, reliable cause-and-effect for short-term prediction. Earthquakes are primarily driven by internal tectonic forces, while solar events affect space weather, creating a complex interaction.
The effect of coronal mass ejections on the angle of Earth’s magnetic field: The Coronal Mass Ejection (CME) whose magnetic field is oriented less than 5 degrees (meaning very southward, opposite Earth’s) relative to Earth’s magnetic field is extremely serious, as it allows for efficient magnetic reconnection, dramatically enhancing geomagnetic storms, power grid failures, and satellite disruption. A CME’s “angle to Earth” refers to the Interplanetary Magnetic Field (IMF) direction within the CME; a southward orientation (small angle, like <5°) allows the fields to “lock” and merge, unleashing huge energy, whereas a northward orientation (large angle) deflects most of the solar plasma.
Preface: AI vision models are artificial intelligence systems, often multimodal (Vision-Language Models or VLMs), that analyze and interpret visual data (images, videos) alongside text, enabling them to “see” and understand the world like humans, performing tasks from object recognition and image captioning to answering questions about visuals and generating new images, by converting visual info into a format comparable to text.
Background: You use NVIDIA TAO (Train, Adapt, Optimize) to rapidly build, customize, and deploy high-performance, domain-specific AI models (especially for vision) with less code, less data, and faster training by leveraging powerful pre-trained foundation models, fine-tuning them with your own data, and optimizing them for efficient inference on edge-to-cloud devices, saving significant time and resources.
The NVIDIA TAO Toolkit is designed to function with both real and synthetic data.
Training with Real Data: The primary function of the TAO Toolkit is to fine-tune NVIDIA’s extensive library of pretrained foundation models using your own proprietary (real-world) datasets. This process is low-code and enables the customization of models for specific use cases without needing deep AI expertise or training from scratch.
Leveraging Synthetic Data: Synthetic data is often used to address the challenges associated with real data collection, such as scarcity, expensive labeling, and rare edge cases.
Models can be initially trained on large volumes of synthetic data generated from tools like NVIDIA Omniverse Replicator or partner platforms (e.g., Sky Engine AI, AI. Reverie, Lexset).
Vulnerability details: (CVE-2025-33208) NVIDIA TAO contains a vulnerability where an attacker may cause a resource to be loaded via an uncontrolled search path. A successful exploit of this vulnerability may lead to escalation of privileges, data tampering, denial of service, information disclosure
Official announcement: Please refer to the link for more details.
Story background: Rowhammer Attacks on GPU Memories are Practical (8th Dec 2025)
Preface: The story unfolds a hidden tale within two different design purpose GPUs (consumer display card and AI (install ROCm)) and reveals the untold behind-the-scenes story that the two sides concealed from the recent.
Background: AMD’s bulletin (Dec 2025) confirms GDDR6-based GPUs are vulnerable, but these are consumer display cards, not ROCm-enabled compute cards. This means AMD acknowledges Rowhammer risk on gaming GPUs, even if ROCm isn’t supported. Rowhammer risk exists for certain display (graphics) cards, specifically those with GDDR6 memory used in workstation and data center environments. Researchers recently demonstrated the “GPUHammer” attack, the first successful Rowhammer exploit on a discrete GPU, which can induce bit flips and compromise data integrity or AI model accuracy.
Rowhammer bit flips happen when repeatedly activating (hammering) specific DRAM rows causes electrical interference that causes adjacent “victim” rows to leak charge and flip their stored bit values. This vulnerability exploits the physical limitations of modern, high-density DRAM chips where cells are packed closely together, making them susceptible to disturbance errors.
Does Rowhammer Show on Screen?
Rowhammer is a memory integrity attack, not a rendering pipeline attack. Here’s why:
The workflow you described (PCIe → GDDR6 → cores → display controller) is correct for rendering.
Rowhammer flips bits in memory rows, potentially corrupting data structures (e.g., textures, buffers, or even code).
If the corrupted data is part of a framebuffer or texture, visual artifacts could appear on screen (e.g., glitches, wrong colors).
But if the corruption affects non-visual data (e.g., shader code, compute buffers), you might see crashes or silent errors instead.
So: it can manifest visually, but only if the hammered rows store display-related data.
AMD Official article: Please refer to the link for details.
