Preface: Web hosting companies can use AMD EPYC 9004 Series processors for demanding and high-traffic websites, but they are more suitable for large-scale or specialized workloads due to their high cost and performance focus on areas like AI, HPC, and cloud-native computing.

Background: During Secure Nested Paging (SNP) initialization, the Reverse Map Table (RMP) is set up by software (firmware) to map system physical addresses to guest memory and enforce page ownership and write permissions. The RMP is a system-wide table, indexed by the System Physical Address (SPA), with each entry corresponding to a 4KB chunk of memory, indicating which owner has access to it and how it can be written to. This is crucial for preventing the hypervisor from maliciously accessing a guest’s private, encrypted memory.

Ref: For AMD SEV-SNP systems, the best hypervisor depends on your specific needs, but Proxmox is a strong contender for a feature-rich, open-source option, while VMware vSphere is an excellent choice for enterprise environments already invested in the VMware ecosystem. For users who prefer Linux, adding a confidential computing kernel to a distribution like Ubuntu enables robust SEV-SNP support through open-source tools like libvir

Vulnerability details: Researchers from ETHz reported that a malicious hypervisor could corrupt the Reverse Map Table (RMP) during Secure Nested Paging (SNP) initialization.

AMD reproduced the issue and determined it is due to a race condition that can occur while the AMD Secure Processor (ASP) is initializing the RMP. This attack could allow a malicious hypervisor to manipulate the initial RMP content, potentially resulting in loss of SEV-SNP guest memory integrity. AMD has released mitigations for this vulnerability.

Official announcement: Please see the link for details –

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

Preface: When running Windows containers on a Windows host, here’s what happens –

Containers share the host kernel — unlike Linux containers on Linux, Windows containers rely on the Windows kernel and some host services.

Isolation is limited — Windows containers are isolated at the process level, but they can access some host resources, especially if configured with elevated privileges.

Background: DLL Search Order

When an application dynamically loads a DLL using functions like LoadLibrary or LoadLibraryEx without providing a complete path, Windows follows a predefined search order to locate the required DLL. This order typically includes:

• The directory from which the application loaded.
• The system directory (%SystemRoot%\system32).
• The 16-bit system directory.
• The Windows directory (%SystemRoot%).
• The current working directory (CWD).
• The directories listed in the PATH environment variable.

Vulnerability details: NVIDIA Display Driver contains a vulnerability where an uncontrolled DLL loading path might lead to arbitrary denial of service, escalation of privileges, code execution, and data tampering.

Supplement:

If a Windows container is configured to use the GPU and the vulnerable NVIDIA driver is present on the host:

DLL Hijacking Risk: If the container or its processes can influence the DLL search path (e.g., by setting the current working directory or placing files in directories searched first), it might be able to exploit the vulnerability.

Container Escape Potential: If the malicious DLL is loaded by a privileged process (e.g., one running as SYSTEM or with elevated rights), it could lead to privilege escalation or container escape.

Remark: Limited by Container Isolation: If the container is running with strict isolation and without elevated privileges or GPU access, the risk is significantly lower, but not zero — especially if the container can manipulate the environment in which the vulnerable driver operates.

To reduce risk (remedy):

Update the NVIDIA driver — Ensure the host is running a patched version that addresses CVE-2025-23309.

Restrict container privileges — Avoid running containers with elevated privileges or access to host directories.

Use absolute paths in DLL loading — If developing software inside containers, always use secure DLL loading practices.

Monitor container file systems — Prevent unauthorized DLLs from being placed in sensitive directories.

Official announcement: Please see the link for details –

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

Preface: Businesses that deploy Akka with .NET span industries like investment banking, retail, healthcare, and social media, and are often found in sectors requiring high-throughput, low-latency systems such as finance, e-commerce, and online gaming. Companies have used Akka.NET to build microservices, power AI solutions, and create resilient, scalable distributed systems that benefit from its actor-based model for fault tolerance and real-time responsiveness.

Background: Akka.NET is a .NET port of the original Akka project, which originated in the Scala/Java community. It provides an idiomatic .NET implementation of the Actor Model, enabling developers to build highly concurrent, distributed, and fault-tolerant systems using C# and F#.

In C# and F#, “System” typically refers to the System namespace, which is a fundamental part of the .NET Framework and .NET Core. This namespace provides access to core functionality that is essential for almost any .NET application, regardless of whether it’s written in C# or F#.

What Happens Due to the Flaw?

1-Malicious Client connects to the cluster over TLS.

2-Because client certificate validation is not enforced, the cluster accepts the connection.

3-The malicious client can:

Send spoofed messages to actors (e.g., fake orders).

Intercept or manipulate actor responses.

Disrupt trading logic or inject latency.

Official announcement: Please see the link for details –

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

https://getakka.net/articles/remoting/security.html

Preface: Computing technology is advancing rapidly, and software development cycles are shrinking. Furthermore, these shorter-than-expected software development cycles are impacting vulnerability management cycles. Vulnerabilities discovered over a year ago might not be taken seriously. However, nothing in the digital world is completely secure. Therefore, it’s recommended not to ignore outdated CVE records. This topic focuses on a vulnerability discovered in December 2022. The submitter announced this vulnerability in September 2023. CVE-2023-53616 was finally published on October 4, 2025.

This article also contains other perspectives. Please enjoy!

Background: Journaled File System (JFS) is a 64-bit journaling file system created by IBM. There are versions for AIX, OS/2, eComStation, ArcaOS and Linux operating systems.

If diUnmount() writes out the inode map and the filesystem is unmounted, shouldn’t that memory be safe from reuse by attackers? Especially since it’s in kernel space and requires root privileges?

Here’s the key point:

Yes, kernel memory is protected and not directly accessible from user space. However, vulnerabilities like this are dangerous even in kernel space, because:

-Kernel code can be triggered indirectly by user actions (e.g., mounting/unmounting filesystems, accessing files).

-If a stale inode structure remains in memory and is reused without proper reinitialization, it can lead to privilege escalation or data corruption.

-Attackers with some level of access (e.g., via a compromised process or container) might exploit such bugs to gain full root access.

Can ioctl Misuse Lead to Exploitation of This Vulnerability?

Yes, absolutely. Misuse of ioctl (Input/Output Control) calls in kernel modules or drivers can be a vector for exploitation, especially when combined with vulnerabilities like the one in JFS_IP. Please see attached diagram for details.

Official announcement: Please see the link for details –  

https://www.tenable.com/cve/CVE-2023-53616