Preface: Sometimes, when a solution is misused or misconfigured, it can use this testing feature as a sword!

Background: AMD SEV (Secure Encrypted Virtualization) is a hardware-based security feature designed to enhance the confidentiality and integrity of virtual machines (VMs) running on AMD EPYC processors. Here are some key points about it:

1. Memory Encryption: SEV encrypts the memory of individual VMs using unique encryption keys. This ensures that neither the hypervisor nor other VMs can access the data of a specific VM.
2. Isolation: SEV creates an isolated execution environment, protecting VMs from potential attacks originating from the hypervisor or other VMs.
3. SEV-SNP (Secure Nested Paging): This is an extension of SEV that adds strong memory integrity protections. It helps prevent malicious hypervisor-based attacks like data replay and memory re-mapping, further enhancing the security of the VMs.
4. Recent Vulnerability: A recent vulnerability (CVE-2024-56161) was discovered in SEV-SNP, which could allow an attacker with local admin privileges to load malicious CPU microcode, compromising the confidentiality and integrity of VMs. AMD has released patches to mitigate this issue.

Vulnerability details: Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious CPU microcode resulting in loss of confidentiality and integrity of a confidential guest running under AMD SEV-SNP.

Office announcement: Please refer to the link for details https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html

Preface: instruction cache (I-cache) and a data cache (D-cache)

This is the smallest and fastest type of cache memory. It’s embedded directly into the CPU, allowing it to operate at the same speed as the CPU. The L1 cache is typically divided into two parts: one for storing instructions (L1i) and one for storing data (L1d).

Background: Instruction prefetching can boost execution performance by fetching data before it is needed. The Cortex-X4 core supports the AArch64 prefetch memory instructions, PRFM PLI, into the L1 instruction cache or L2 cache.  These instructions signal to the memory system that memory accesses from a specified address are likely to occur soon. The memory system takes actions that aim to reduce the latency of memory accesses when they occur. The PRFM PLD and PRFM PST instructions perform preloading in the L1 data cache, L2 cache, or L3 cache. PRFM PLD and PRFM PST instructions translate through the Data TLB. The PRFM PLI instruction performs preloading to the L1 instruction cache and L2 cache. Instruction preloading is performed in the background. PRFM PLI instructions translate through the Instruction TLB.

Vulnerability details: An issue has been identified in some Arm-based CPUs that may allow an unprivileged context to trigger a data memory-dependent prefetch engine to fetch the contents of a privileged location (for which it does not have read permission) and consume those contents as an address that is also dereferenced. 

Note that this issue does not affect guest-to-guest and guest-to-hypervisor isolation guarantees. Likewise, in configurations with RME enabled, Granule Protection Checks (GPC) are honoured by the prefetcher. 

Official details: Please refer to the link for details –

https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881

https://nvd.nist.gov/vuln/detail/CVE-2024-7881

Preface: Mars is very cold, with an average temperature of -62 degrees Celsius. Therefore, human living environments need to be designed to withstand extreme cold. Fortunately, however, these temperatures are not beyond our control. In fact, there are cities on Earth where temperatures have reached such low levels. Maybe, this is what Elon Musk meant by his recent (January 2025) speech!

Background: The Node.js Websocket Server can handles several tasks related to the OS Web GUI, including report management, WebSockets, Web CLI in the GUI, and proxying traffic to/from the administrative web GUI.

Node[.]js for WebSockets Common Vulnerabilities

Security Focus:

No Authentication During the Handshake Process: The problem here is that the WebSocket protocol does not allow the server to authenticate the client during the handshake process. Only normal HTTP connection mechanisms can be used. These include HTTP and TLS authentication and cookies. The upgraded handshake still happens from HTTP to WebSocket. However, HTTP sends authentication information directly to WS. This attack can be exploited and we call this attack Cross-Site WebSocket Hijacking.

Data masking: The WebSockets protocol uses this to prevent things like proxy cache poisoning. However, there is a problem. Blocking prevents security tools from performing actions such as identifying patterns in traffic. Software such as DLP (Data Loss Prevention) don’t even know that WebSockets exist. This makes it impossible for them to profile WebSocket traffic. This also makes these software programs unable to identify malicious JavaScript and data leakage, etc.

For more professional advice, you can refer to the Fortinet security advisory on this topic. Please refer to the link for details – https://www.fortiguard.com/psirt/FG-IR-24-535

Preface: Is io_uring secure? io_uring has produced many security problems. Google has found it necessary to either completely forego io_uring or severely limit its use to trusted code.

Background: io_uring is an asynchronous I/O interface for the Linux kernel. An io_uring is a pair of ring buffers in shared memory that are used as queues between user space and the kernel: Submission queue (SQ): A user space process uses the submission queue to send asynchronous I/O requests to the kernel.

eventfd(2) is a Linux-specific synchronization mechanism. io_uring is capable of posting events on an eventfd instance whenever completions occur.

Vulnerability details: In the Linux kernel, the following vulnerability has been resolved: io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period io_eventfd_do_signal() is invoked from an RCU callback, but when dropping the reference to the io_ev_fd, it calls io_eventfd_free() directly if the refcount drops to zero. This isn’t correct, as any potential freeing of the io_ev_fd should be deferred another RCU grace period. Just call io_eventfd_put() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.

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