The Linux kernel CVE-2023-54324 was released on December 30, 2025. Do you think that is valuable to know? (2nd Jan 2026)

Preface: Essentially, when security experts read vulnerability lists, the priority is time-dependent. For example, if you read a CVE reference document on January 2, 2025, but the document’s starting date is 2023, there’s a 99% chance you’ll ignore it. This makes sense, after all, it’s two years ago. According to vendor practice, when patches are released, they prioritize notifying customers. The timing of public releases depends on the vendor’s policy. But what made me interested in this CVE and want to delve deeper? In fact, when you investigate further, you discover more information than expected.

You’re welcome to continue exploring.

Background: Instead of the md driver’s classic RAID, Android utilizes the Device Mapper (DM) framework—specifically the same dm-ioctl.c interface you noted earlier—to implement modern, mobile-specific storage features.

The Device Mapper framework operates within standard kernel memory space and uses the general-purpose Linux memory allocators (kmalloc, the buddy allocator, or potentially the Contiguous Memory Allocator (CMA) for large buffers).

However, seems the major remedy  is implement a tool ( rw_semaphore devices_lock). When the Device Mapper drivers (dm-ioctl.c, dm-core.h, and dm-table.c) are used on an Android smartphone with a Qualcomm processor. The memory used by the storage drivers (drivers/md/) and the memory managed by the graphics drivers (Qualcomm’s KGSL) are distinct and reserved for different purposes:

Storage (Device Mapper) Memory

The Device Mapper framework operates within standard kernel memory space and uses the general-purpose Linux memory allocators (kmalloc, the buddy allocator, or potentially the Contiguous Memory Allocator (CMA) for large buffers).

  • When the storage drivers perform tasks like encryption (dm-crypt) or integrity checks (dm-verity), they are processing data from the main system RAM or directly from the physical storage chip using Direct Memory Access (DMA).
  • The system uses memory pools like ION or ashmem to manage shared buffers between the kernel and user-space applications for storage tasks. These are separate from GPU pools. 

Vulnerability details: In the Linux kernel, the following vulnerability has been resolved.

dm: fix a race condition in retrieve_deps There’s a race condition in the multipath target when retrieve_deps races with multipath_message calling dm_get_device and dm_put_device. retrieve_deps walks the list of open devices without holding any lock but multipath may add or remove devices to the list while it is running. The end result may be memory corruption or use-after-free memory access.

See this description of a UAF with multipath_message(): https://listman.redhat.com/archives/dm-devel/2022-October/052373.html Fix this bug by introducing a new rw semaphore “devices_lock”. We grab devices_lock for read in retrieve_deps and we grab it for write in dm_get_device and dm_put_device.

Official announcement: Please refer to the link for details. https://www.tenable.com/cve/CVE-2023-54324

Extraterrestrial life comes from an unknown universe. Interstellar objects also originate from the unknown universe. From a scientific perspective, there is some kind of connection between them. (31st Dec 2025)

Preface: On December 31, 2025, interstellar comet 3I/ATLAS is well past its closest approach to Earth (December 19, 2025) and is already heading back out of the solar system on a hyperbolic trajectory, still visible with telescopes in the Northern Hemisphere as it moves through the constellation Leo, offering a unique opportunity for astronomers to study this visitor from another star system before it disappears forever!

Background: An interstellar object discovered in July that is travelling at high speed and unlike anything seen before, touches on a fascinating area of modern astronomy, particularly the relatively new field of identifying celestial visitors from beyond our solar system. 3I/ATLAS carrying chemical clues that suggest its parent system was rich in carbon dioxide and possibly very old, originating from the Milky Way’s thick disk. While some of its anomalies sparked speculative discussions, the scientific consensus firmly identifies it as a fascinating, albeit unusual, natural comet. Its study is a goldmine for understanding the vast diversity of planetary formation processes across the galaxy. Harvard astrophysicist Avi Loeb has kept the interstellar object 3I/ATLAS at a Rank 4 on his Classification Scale (0-10, 10 being alien tech) because, despite numerous anomalies like an unusual anti-tail and unexplained mass loss, the data isn’t conclusive enough for a higher rating, though he believes its features suggest potential technological origin, keeping it significantly above natural comets like ‘Oumuamua, while awaiting more data from upcoming observations.

Mainstream perspective: The scientific definition based on causality is the cornerstone of scientific inquiry and the foundation of human understanding of the world. However, causality in science is not a simple definition. We may know that the 3I/ATLAS interstellar object does not have conclusive evidence that it is an extraterrestrial visitor. However, extraterrestrial life originates from an unknown universe. Interstellar objects also originate from this unknown universe. From a scientific perspective, there is some kind of connection between them.

Today is the last day of 2025. Perhaps it’s time to say goodbye to 2025.

Andrea Bocelli, Sarah Brightman – Time To Say Goodbye –

CVE-2025-43529: Apple Multiple Products Use-After-Free WebKit Vulnerability (31-12-2025)

NVD Published Date:12/17/2025

NVD Last Modified:18/12/2025

Preface: Apple Multiple Products Use-After-Free WebKit Vulnerability

Required Action – Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.

Date Added – 12/15/2025

Due Date – 01/05/2026

Ref: CISA’s BOD 22-01 isn’t specifically for cloud services but mandates U.S. federal agencies to rapidly fix high-risk, known exploited vulnerabilities (KEVs) listed in CISA’s catalog, including those in cloud environments, by providing strict timelines for remediation. It requires agencies to update vulnerability management procedures, apply to all software/hardware on federal systems (even third-party clouds), and focus on the CISA KEV catalog for critical patching, thereby significantly reducing federal cyber risk.

Background: Chrome used to use WebKit but now uses its own fork called Blink, except on Apple’s iOS/iPadOS where it’s forced to use WebKit due to Apple’s rules, while Blink powers most other desktop/mobile versions and is a descendant of WebKit. Think of it like this: Chrome started with WebKit, then created Blink from it for speed, but iOS versions remain WebKit-based.

The version of Google Chrome available on Apple’s iOS and iPadOS devices is indeed required to use the underlying WebKit framework provided by the operating system, which is the exact same engine that powers Apple’s own Safari browser.

Apple’s iOS and its Safari browser do not natively use Vulkan or DirectX; instead, they rely exclusively on Apple’s own proprietary graphics API, called Metal.

Google has to build its browser on top of Apple’s WebKit framework, which itself integrates seamlessly with Apple’s comprehensive memory management systems like ARC and the iOS kernel’s memory allocation routines. Metal plays a critical role in how the browser draws things incredibly fast on your screen, leveraging the GPU’s power, but it is not a general-purpose memory manager for the entire application’s operational needs.

Vulnerability details: A use-after-free issue was addressed with improved memory management. This issue is fixed in watchOS 26.2, Safari 26.2, iOS 18.7.3 and iPadOS 18.7.3, iOS 26.2 and iPadOS 26.2, macOS Tahoe 26.2, visionOS 26.2, tvOS 26.2. Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 26. CVE-2025-14174 was also issued in response to this report.

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

About 3rd part design weakness impact Intel® Xeon® 6 Processors with P-cores with Intel® TDX Connect (29-12-2025)

Last revised: 12/09/2025

Preface: Intel’s Xeon 6 processors represent a fascinating shift in the landscape of data center computing, moving toward a hybrid architecture that optimizes for different workloads with specialized cores. The P-core version, codenamed Granite Rapids, built entirely of Performance-cores for heavy compute and AI workloads, is accurate and highlights a significant technological leap in server processing capabilities. This new generation aims to deliver unprecedented performance and efficiency to meet the increasing demands of modern data centers, which are grappling with massive data volumes and the computational intensity of artificial intelligence.

Background: Intel® TDX Connect is specifically highlighted as a key feature on Intel® Xeon® 6 Processors with P-cores (Performance-cores) to enable confidential computing for connected devices like GPUs. Intel’s P6 architecture, as part of modern high-speed systems using PCI Express (PCIe), relies on SERDES (Serializer/Deserializer) technology, especially for PCIe 3.0 and newer, to handle high data rates through serial links, though P6 itself refers to older processor generations, the concept of using SERDES for high-speed I/O like PCIe is fundamental, with newer Intel CPUs using advanced SerDes for PCIe 4.0, 5.0, and 6.0 to achieve massive bandwidth for AI and data centers.

Does the Intel P6 use PCIe SERDES?

Yes, Intel’s P6 architecture, as part of modern high-speed systems using PCI Express (PCIe), relies on SERDES (Serializer/Deserializer) technology, especially for PCIe 3.0 and newer, to handle high data rates through serial links, though P6 itself refers to older processor generations, the concept of using SERDES for high-speed I/O like PCIe is fundamental, with newer Intel CPUs using advanced SerDes for PCIe 4.0, 5.0, and 6.0 to achieve massive bandwidth for AI and data centers.

Vulnerability details: [CVE-2025-9612] Improper validation of integrity check value in PCI Port for some Intel® platforms with Integrity and Data Encryption (IDE) for PCIe Base Specification Revision 5 or higher within Ring 0: Bare Metal OS may allow an information disclosure and escalation of privilege. System software adversary with a privileged user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (low), integrity (low) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Official announcement: Please refer to the link for details –

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01409.html

CVE-2025-33223: NVIDIA Isaac Launchable contains a vulnerability (29th Dec 2025)

Official Updated 12/22/2025 09:21 AM

Preface: The ability to launch NVIDIA Isaac Lab via NVIDIA Brev (Cloud) is fundamentally driven by the need to democratize access to high-performance robotics simulation and AI development environments, circumventing significant hardware and setup barriers. This collaboration between Isaac Lab and Brev offers a streamlined, low-friction pathway for developers and researchers to leverage powerful, preconfigured GPU resources in the cloud.

Background: Isaac Lab requires a compatible version of Isaac Sim to run. An “Isaac Lab Launchable” is an installation option, such as via NVIDIA Brev (Cloud), to quickly get the environment running. The Launchable provides the correct Isaac Sim/Python setup, but you still use env_config[.]yaml within your scripts to define what runs on that platform.

In essence, Issac Lab use env_config[.]yaml to specify tasks (like Isaac-Ant-v0) within your Python training scripts (e.g., train[.]py)The environment command

isaaclab/scripts/reinforcement_learning/skrl/train[.]py –task=Isaac-Ant-v0 specifically targets the Isaac-Ant-v0 task. If train[.]py or related scripts dynamically construct shell commands from these inputs without validation, that’s a classic command injection risk.

Vulnerability details: CVE-2025-33223 – NVIDIA Isaac Launchable contains a vulnerability where an attacker could cause an execution with unnecessary privileges. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, denial of service, information disclosure and data tampering.

Official announcement: Please refer to the link for details –

https://nvidia.custhelp.com/app/answers/detail/a_id/5749

Upcoming Mars solar conjunction (around late December 2025/early January 2026) will further delay recovery of Maven efforts.(26-12-2025)

Preface: On Dec. 16 and 20, 2025 NASA’s Curiosity team used the rover’s Mastcam instrument in an attempt to image MAVEN’s reference orbit, but MAVEN was not detected.

The initial loss of contact on December 6, 2025, was due to a routine orbital blackout as MAVEN passed behind Mars, but an unspecified anomaly prevented signal reacquisition when it reemerged; however, the upcoming Mars solar conjunction (around late December 2025/early January 2026) will further delay recovery efforts, as the Sun blocks communication paths, but it wasn’t the cause of the initial December 6th silence.

Background: The Earth-Sun conjunction timing isn’t perfectly annual because Earth’s orbit is an ellipse (oval), not a perfect circle, causing its distance and speed to the Sun to vary, and long-term orbital changes (Milankovitch cycles) also shift dates slightly over millennia, meaning solar conjunctions (when the Sun is between Earth and another planet) and even peak closeness (perihelion) happen at different Earth-orbit points annually.

The planetary orbits are elliptical and speeds vary (Kepler’s Laws), but a solar conjunction (when a planet passes behind the Sun from Earth’s perspective) typically happens once per orbit for that specific planet, around every 1-2 years for inner planets, or 2-5 years for Mars, due to Earth catching up, not multiple times annually for the same planet because of its own varying speed; the elliptical nature and speed changes influence when and how often these conjunctions occur over years, making them predictable cycles, not random occurrences within a single year for one planet.

Remark: Mercury and Venus are inner planets

Official announcement: Please refer to the link for details – https://science.nasa.gov/blogs/maven/2025/12/23/nasa-works-maven-spacecraft-issue-ahead-of-solar-conjunction/

Additional: http://www.antihackingonline.com/science/if-3i-atlas-did-not-arise-naturally-then-advanced-civilizations-could-send-carrier-signals-to-interfere-with-mavens-signals-20th-dec-2025/

When 3I/ATLAS Meets Santa Claus (24th Dec 2025)

Preface: O come, all ye faithful, joyful and triumphant,

O come ye, O come ye, to Bethlehem.

But this time, 3I/ATLAS’s destination is Jupiter!

No worries! Santa Claus is here to see you!

Background: Halley’s Comet, the famous periodic comet, last appeared in 1986 and is expected to return to Earth’s vicinity in mid-2061, reaching its closest point to the Sun (perihelion) around July 28, 2061, and closest to Earth on July 29, 2061.

Remark: Halley’s Comet was at perihelion around February 9, 1986.

Harris Comet (like Halley’s) is a native solar system comet from our Oort Cloud, looping regularly, while 3I/ATLAS is a rare visitor from another star system, an interstellar object with unique chemistry (more CO2, nickel) and extremely high speed, showing it’s not bound by our Sun’s gravity and highlighting differences in stellar nurseries across the galaxy.

Despite centuries of scientific exploration and research, our planet Earth still harbors an astonishing number of unknowns and some unexplained phenomena. From the depths of the mantle to the edge of the atmosphere, mysterious events and structures abound.

From a technical perspective, we’ve primarily focused on 3I/ATLAS over the past few months. In fact, many unknown phenomena have occurred in the past in earth, and we have no conclusions. But we cannot forget the structure of the Earth; the formation of the Moon precisely controls the tides of the ocean. It is actually the tidal friction generated by the Moon’s gravitational pull that actively slows the Earth’s rotation, rather than assisting it in spinning faster. Furthermore, the Earth’s atmosphere’s primary role in mitigating solar storms is absorption and shielding, working in conjunction with the planet’s magnetic field to protect life on the surface from harmful radiation and charged particles. It serves as a planetary “kevlar vest” against the energetic onslaught from the Sun.

The details above demonstrate that Earth possesses the ability to protect itself. Perhaps we should thank God, or perhaps we should thank the advanced civilization that created this environment.

So we are not alone!

Best wishes: Wishing you all the best in 2026 and a Merry Christmas!

CVE-2025-33226: NVIDIA NeMo Framework for all platforms contains a vulnerability (24th Dec 2025)

Official Updated 12/12/2025 02:17 PM

Preface: NVIDIA NeMo is a versatile, end-to-end platform used across a vast spectrum of industries, primarily to build, customize, and deploy generative AI agents and applications, such as custom chatbots and specialized assistants. Its primary users are companies in the computer software industry, but its use cases span many different sectors, including energy, telecommunications, financial services, healthcare, and retail.

NeMo is the framework for building models, while NIM (NVIDIA Inference Microservices) provides pre-packaged tools to easily deploy and manage those (and other) AI models as APIs, with NIM often using NeMo’s customized models for inference, creating a unified ecosystem.

Background: Uploading model checkpoints from the NVIDIA NeMo framework to NVIDIA NIM is essential for streamlining the transition from model development and training to optimized, scalable, production-ready inference. This integration merges the development power of NeMo with the robust, deployment-focused capabilities of NIM.

The process is more than a simple file transfer; it is a critical step in a comprehensive, end-to-end AI lifecycle management strategy. NVIDIA NeMo is a powerful framework for building, training, and fine-tuning large language models (LLMs) and other generative AI models, producing specialized .nemo checkpoints that contain model configurations and weights. NVIDIA NIM, or NVIDIA Inference Microservices, then takes these trained, domain-specific models and packages them into prebuilt, optimized, and secure microservices for deployment across various environments, whether in the cloud, on-premises data centers, or at the edge.

The restore_from() method is a function used for model loading and restoration. It allows you to: 

  • Load a previously trained model instance, including its weights and configuration, from a saved .nemo file.
  • Resume training from a specific point or perform fine-tuning/inference with a pre-trained model

Vulnerability details: CVE-2025-33226: NVIDIA NeMo Framework for all platforms contains a vulnerability where malicious data created by an attacker may cause a code injection. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, information disclosure, and data tampering.

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

CVE-2025-33235 is specifically about a vulnerability in NVIDIA’s implementation, not PyTorch or NVRx directly (23rd Dec 2025)

Official Updated 12/12/2025 02:20 PM

Preface: Given Google’s efforts to make its hardware compatible with PyTorch, why is the NVIDIA Resiliency Extension (NVRx) still needed? The answer lies in the complementarity of these technologies, the realities of large-scale distributed systems, and the practical necessity to ensure training efficiency and fault tolerance, especially when using NVIDIA GPUs, which remain the mainstream platform for AI development. While Google is working to make its Tensor Processing Units (TPUs) more compatible with PyTorch to provide an alternative, the NVIDIA Resiliency Extension aims to address the specific and pressing challenges encountered when performing large-scale distributed PyTorch training on NVIDIA’s widely used hardware, such as hardware on cloud platforms like Google Cloud.

Background: The open-source machine learning framework PyTorch was originally developed by researchers at Facebook AI Research (now Meta AI). It was first publicly released in September 2016. PyTorch-based workloads are artificial intelligence (AI) and machine learning (ML) tasks and applications that are developed, trained, and run using the PyTorch open-source deep learning framework.

The NVIDIA Resiliency Extension (NVRx) integrates multiple resiliency-focused solutions for PyTorch-based workloads. Users can modularly integrate NVRx capabilities into their own infrastructure to maximize AI training productivity at scale. The NVIDIA Resiliency Extension (NVRx) is a specific Python package that integrates several solutions to minimize downtime and maximize the effective training time for PyTorch-based workloads running on NVIDIA infrastructure. NVRx is a Python package that framework developers and users can modularly integrate into their own infrastructure. It is used in major NVIDIA frameworks like the NVIDIA NeMo Framework for building large language models, providing the underlying machinery for their resilient training capabilities.

NVRx provides utilities that run the actual checkpoint saving routines in the background. It employs mechanisms, often leveraging torch.multiprocessing, to fork a separate, temporary process dedicated to handling the I/O operations after the data has been quickly staged from GPU memory to CPU buffers.

Vulnerability details: CVE-2025-33235 – NVIDIA Resiliency Extension for Linux contains a vulnerability in the checkpointing core, where an attacker may cause a race condition. A successful exploit of this vulnerability may lead to information disclosure, data tampering, denial of service, or escalation of privileges.

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

About CVE-2025-32210: NVIDIA Isaac Lab, a story can tell! (22-12-2025)

Official Updated 12/12/2025 02:19 PM

Preface: The primary difficulties in robotics learning involve bridging the gap between simulation and reality (the “reality gap”), enabling robust perception and decision-making in unpredictable environments, handling complex physical interactions like contact dynamics, ensuring safety and security, addressing high costs and lack of standardization, and overcoming workforce skill gaps, all while managing computational and power limitations.

Background: Isaac Lab uses NVIDIA Isaac Sim’s capabilities for realistic virtual environments, allowing researchers to train complex robot behaviors efficiently through parallel simulation and data generation, then transfer these policies to physical robots. The primary difficulties Isaac Lab tackles are:

While the physical world remains the definitive testbed, the acquisition of physical interaction data with robots is expensive, time-consuming, and often necessitates specialized instrumentation. These limitations are especially acute in rare but safety-critical situations. Events such as high-speed collisions, hardware malfunctions, or navigation in unpredictable human environments are difficult to reproduce and pose significant risks to equipment and human safety.

NVIDIA Isaac Sim manages computational and power limitations through GPU-accelerated design, customizable performance settings, and scalable deployment options, allowing users to balance performance, fidelity, and resource consumption. This approach empowers developers to tailor the simulation environment to their specific hardware capabilities and project needs, from local workstations to cloud-based multi-GPU setups.

Key contributions of Isaac Lab

• Modular and scalable framework: Built on NVIDIA Omniverse, enabling high-fidelity, GPU-accelerated simulation for complex robots and tasks.

• Advanced sensor simulation: Supports tiled RTX rendering, Warp-based custom sensors, and physics-based data for rich observation spaces.

• Seamless teleoperation and data collection: Integrates spacemouse, VR headsets, and other devices for large-scale demonstration capture.

• Extensive environment suite: Provides diverse, ready-to-use environments for reinforcement learning, imitation learning, and sim-to-real research.

Vulnerability details: CVE-2025-32210 – NVIDIA Isaac Lab contains a deserialization vulnerability.  A successful exploit of this vulnerability might lead to code execution.

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

antihackingonline.com