Point of view – IOLeak – CPU Side Channel Attacks  23-05-2025

Preface: Hertzbleedis about inferring secrets from timing differencescaused by how CPUs adjust their frequency under load.

Background: The Hertzbleed vulnerability does not specifically target the L2 cache of AMD CPUs. Instead, it exploits a broader mechanism related to dynamic frequency scaling — a feature used by modern CPUs (including AMD Zen 2 and Zen 3) to adjust clock speeds based on workload and thermal conditions.

How is IOLeak Different?

FeatureHertzbleedIOLeak
Primary TriggerData-dependent CPU workloadI/O latency and interaction with CPU
Leakage SourceFrequency scaling due to computationFrequency scaling influenced by I/O timing
FocusCryptographic operations (e.g., SIKE)Broader I/O-related operations
NoveltyFirst to show DVFS can leak data remotelyFirst to show I/O latency can amplify DVFS-based leakage

Ref: AMD’s DVFS (Dynamic Voltage and Frequency Scaling) is a power management technique that dynamically adjusts the CPU’s voltage and frequency based on the current workload. This allows for a balance between performance and energy consumption by reducing both when the workload is light and boosting them when more processing power is needed. DVFS is used in AMD processors to optimize power usage and improve battery life in mobile devices, as well as to reduce energy costs in servers.

Vulnerability details: The researchers provided AMD with a summary of their comments and findings, detailed in a paper titled “IOLeak Side-Channel Attacks Exploiting CPU Frequency Scaling and I/O Latency.”

AMD reviewed the summary and believes this attack is similar to previously disclosed side-channel attacks such as “Hertzbleed” and that existing mitigation recommendations for such attacks remain applicable to mitigate the techniques described in the researchers’ summary.

Official announcement: Please see the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7042.html

CVE-2025-27558: FragAttacks against mesh networks (21-05-2025)

Preface: A Mesh Basic Service Set (MBSS) is a self-contained wireless network created by a group of interconnected mesh stations (STAs). Each mesh station can act as both an access point and a mesh node, enabling communication and data sharing within the mesh network. The MBSS uses a “mesh profile” to define the network’s characteristics, including a Mesh ID and other parameters. Unlike traditional Wi-Fi setups that rely on a single router, mesh networks create a more resilient, decentralized system.

Background: FragAttacks, short for Fragmentation and Aggregation attacks, are a category of Wi-Fi vulnerabilities that exploit design flaws in how Wi-Fi devices handle data packets. These flaws affect a wide range of Wi-Fi devices, potentially allowing attackers to steal information or disrupt network services.

Vulnerability details: IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.

Ref: CVE-2020-24588: The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn’t require that the A-MSDU flag in the plaintext QoS header field is authenticated. Against devices that support receiving non-SSP A-MSDU frames (which is mandatory as part of 802.11n), an adversary can abuse this to inject arbitrary network packets.

Official announcement: For details, please refer to the link –

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

CVE-2025-37991 – PA-RISC: Fix double SIGFPE crash (21-05-2025)

Preface: In the Linux Kernel, SIGFPE (Signal Floating-Point Exception) indicates a computational error, specifically related to floating-point arithmetic or integer arithmetic errors. This signal is triggered by events like floating-point overflow, underflow, or division by zero. While named “Floating-Point Exception,” it actually covers a broader range of arithmetic errors.

Background: What triggers SIGFPE?

  • Floating-point errors: These include overflow (exceeding the maximum representable value), underflow (falling below the minimum non-zero value), and division by zero.
  • Integer errors: Specifically, integer division by zero can also trigger SIGFPE. 

How it works in the Linux Kernel:

  • When a process encounters an arithmetic error that triggers SIGFPE, the kernel sends this signal to the process.
  • By default, if a signal handler is not registered for SIGFPE, the process will be terminated.
  • If a signal handler is registered, the handler can be used to attempt to recover from the error, such as by retrying the operation or taking alternative actions.
  • The si_code field in a signal handler can provide more information about the specific type of arithmetic error that caused SIGFPE. For example, FPE_INTDIV indicates integer division by zero, according to a post on Stack Overflow

Vulnerability details: Camm Maguire noticed that on PA-RISC a SIGFPE exception will crash an application with a second SIGFPE in the signal handler.  Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, it hit a floating-point store in fpe_func almost immediately.

When the T bit is set , an assist exception trap occurs when when the co-processor encounters *any* floating-point instruction except for a double store of register %fr0.  The latter cancels all pending traps. 

Remedy: Linux fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.

Official announcement: For details, please refer to the link –https://nvd.nist.gov/vuln/detail/CVE-2025-37991

CVE-2025-47935 and CVE-2025-47944: About Multer design weakness (19-05-2025)

Preface: In a typical web application, there are three layers of middleware: Web server middleware. Application server middleware and Database middleware. A common request for file upload applications.

For example: uploading user avatars, attaching documents or handling multimedia content.

Multer is a node.js middleware for handling multipart/form-data, which is primarily used for uploading files.

Background: Express is the most popular Node.js web framework, and is the underlying library for a number of other popular Node.js frameworks.

Multer is a popular middleware for handling file uploads in Node. js applications, especially those built with Express . It makes receiving, validating, and storing files from HTTP requests simple and straightforward.

Vulnerability details: Multer is a node.js middleware for handling `multipart/form-data`. Versions prior to 2.0.0 are vulnerable to a resource exhaustion and memory leak issue due to improper stream handling. When the HTTP request stream emits an error, the internal `busboy` stream is not closed, violating Node.js stream safety guidance. This leads to unclosed streams accumulating over time, consuming memory and file descriptors. Under sustained or repeated failure conditions, this can result in denial of service, requiring manual server restarts to recover. All users of Multer handling file uploads are potentially impacted. Users should upgrade to 2.0.0 to receive a patch. No known workarounds are available.

Official announcement: For details, please refer to the link –

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

https://nvd.nist.goc/vuln/detail/CVE-2025-47944

Part 1: Spectre-v2 Domain Isolation, does it fight against variants? (19-05-2025)

Preface: In computer architecture, a branch predictor is a digital circuit that tries to guess which way a branch will go before this is known definitively.

Background: Although the Spectre v2 vulnerability has been protected by domain isolation technologies such as IBPB, eIBRS and BHI_NO, which prevent attackers from training the indirect branch predictor with their own code, the VUSec security research team found that as long as the attacker allows the code to train itself (that is, training and speculative execution occur in the same privileged domain), the Spectre v2 attack can be re-implemented.

Modern CPUs use branch predictors to guess the target of indirect branches (like function pointers or virtual calls) to keep the pipeline full and improve performance. These predictors are part of the speculative execution engine.

How Attackers Use Their Own Code?

1. Attackers Use Their Own Code

2.Triggering Misprediction:

– When the victim code runs, the CPU may speculatively execute based on the attacker’s training.

– If the attacker has set things up correctly, the CPU speculatively executes code paths that leak sensitive data (e.g., via cache timing).

3.The attacker then uses cache timing attacks (like Flush+Reload or Prime+Probe) to infer what was speculatively executed, revealing secrets.

White paper: Researchers from VU Amsterdam have shared with AMD a paper exploring the effectiveness of domain isolation against Spectre-v2 type attacks.

AMD believes the techniques described by the researchers are not applicable to AMD products.

For more details, please refer to link – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7034.html

CVE-2025-47436: Heap-based Buffer Overflow vulnerability in Apache ORC. (15-5-2025)

Preface: Traditional row-based formats for data normalization have several limitations:

Complex Queries: Normalization often requires joining multiple tables to retrieve data, which can make queries more complex and slower.

Maintenance Challenges: Maintaining a highly normalized database can be more difficult, as changes to the schema may require updates to multiple tables.

Background: Apache ORC (Optimized Row Columnar) is a free and open-source, column-oriented data storage format designed for use in Hadoop and other big data processing systems. It was created to address the limitations of traditional row-based formats, providing a more efficient way to store and process large datasets. ORC is widely used by data processing frameworks like Apache Spark, Apache Hive, Apache Flink, and Apache Hadoop.

Vulnerability details: Heap-based Buffer Overflow vulnerability in Apache ORC. A vulnerability has been identified in the ORC C++ LZO decompression logic, where specially crafted malformed ORC files can cause the decompressor to allocate a 250-byte buffer but then attempts to copy 295 bytes into it. It causes memory corruption.

Remedy: This issue affects Apache ORC C++ library: through 1.8.8, from 1.9.0 through 1.9.5, from 2.0.0 through 2.0.4, from 2.1.0 through 2.1.1. Users are recommended to upgrade to version 1.8.9, 1.9.6, 2.0.5, and 2.1.2, which fix the issue.

Official announcement: Please see the link for details –

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

Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection – Part 2 (14-05-2025)

Preface: Before reading the detailed information, it is recommended to read Part 1 first.

Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection (Part 1)  –

http://www.antihackingonline.com/under-our-observation/privilege-desynchronization-cross-privilege-spectre-attacks-with-branch-privilege-injection-14-05-2025/

Technical details: It is to ensure the serialization of memory access. The internal operation is to add some delays in a series of memory accesses to ensure that the memory access after this instruction occurs after the memory access before this instruction is completed (no overlap occurs).

Performs a serializing operation on all load-from-memory instructions that were issued prior the LFENCE instruction. Specifically, LFENCE does not execute until all prior instructions have completed locally, and no later instruction begins execution until LFENCE completes.

AMD’s AutoIBRS (Automatic Indirect Branch Restricted Speculation) is designed to mitigate timing-based attacks, such as Spectre. AutoIBRS helps avoid the performance overhead associated with LFENCE by automatically restricting speculative execution of indirect branches. This mechanism reduces the need for frequent LFENCE instructions, thereby minimizing delays while still protecting against timing vulnerabilities.

Cyber security focus provided by ETH Zurich: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

If supported by the processor, operating systems enable eIBRS or AutoIBRS to mitigate cross-privilege BTI attacks. These mitigations need to keep track of the privilege domain of branch instructions to work correctly, which is non-trivial due to the highly complex and asynchronous nature of branch prediction. For example, previous work has shown that branch predictions are updated before branches retire, and in certain cases even before they are decoded. Our first challenge revolves around analyzing the behavior of restricted branch prediction under race conditions.

Official announcement: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

Please see the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7030.html

Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection (14-05-2025)

Preface: Enhanced IBRS (eIBRS) and Automatic IBRS (AutoIBRS) are features designed to mitigate the Spectre V2 vulnerability, which affects speculative execution in CPUs.

Background: AutoIBRS is a similar feature introduced by AMD in their Zen 4 processors. It automatically manages IBRS mitigation resources across privilege level transitions, offering better performance compared to Retpoline. This feature is particularly beneficial for AMD’s Ryzen 7000 and EPYC 9004 series processors.

AMD EPYC 9004 series processors are designed for data centers and high-performance computing (HPC) environments. They offer features like up to 96 “Zen 4” cores, 12 channels of DDR5 memory, and PCIe Gen5 support.

Cyber security focus provided by ETH Zurich: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

If supported by the processor, operating systems enable eIBRS or AutoIBRS to mitigate cross-privilege BTI attacks. These mitigations need to keep track of the privilege domain of branch instructions to work correctly, which is non-trivial due to the highly complex and asynchronous nature of branch prediction. For example, previous work has shown that branch predictions are updated before branches retire, and in certain cases even before they are decoded. Our first challenge revolves around analyzing the behavior of restricted branch prediction under race conditions.

Official announcement: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

Please see the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7030.html

CVE-2025-21460: Improper Input Validation in Automotive Software platform based on QNX. (13th May 2025)

Preface: As of June 26, 2023, QNX software is now embedded in over 255 million vehicles worldwide, including most leading OEMs and Tier 1s, such as BMW, Bosch, Continental, Dongfeng Motor, Geely, Ford, Honda, Mercedes-Benz, Subaru, Toyota, Volkswagen, Volvo, and more.

Background: In Automotive Ethernet Audio Video Bridging (eAVB), reliable communication is not limited to audio alone. eAVB ensures efficient and reliable communication for both audio and video data, as well as other types of data that require low latency and high synchronization. This includes applications such as infotainment systems, advanced driver-assistance systems (ADAS), and vehicle-to-vehicle communication.

The standards for eAVB, including Time-Sensitive Networking (TSN), provide guaranteed latencies and the ability to build redundant network paths for safety-critical communications. This makes eAVB a versatile solution for various types of data within the automotive network.

Vulnerability details:

Improper Input Validation in Automotive Software platform based on QNX

Description: Memory corruption while processing a message, when the buffer is controlled by a Guest VM, the value can be changed continuously.

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

About CVE-2025-37889 – ASoC framework Consistently treat platform_max as control value (12th May 2025)

Preface: The overall project goal of the ALSA System on Chip (ASoC) layer is to provide better ALSA support for embedded system-on-chip processors.

Advanced Linux Sound Architecture (ALSA) is a software framework and part of the Linux kernel that provides an application programming interface (API) for sound card device drivers.

Background: The snd_soc_put_volsw() function is part of the ALSA System on Chip (ASoC) layer in the Linux kernel. It is included in the kernel source, but whether it is available by default depends on the specific kernel configuration and the presence of ASoC support. Here’s a brief overview of its features:

Purpose: It sets the volume control values for the sound subsystem.

Arguments: It takes two arguments: kcontrol, which represents the mixer control, and ucontrol, which contains the control element information.

Return Value: It returns 0 on success.

Vulnerability details: ASoC: ops: Consistently treat platform_max as control value This reverts commit 9bdd10d57a88 (“ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min”), and makes some additional related updates.

Speculated this is an enhancement and remediation for CVE-2022-48917

In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min While the $val/$val2 values passed in from userspace are always >= 0 integers, the limits of the control can be signed integers and the $min can be non-zero and less than zero. To correctly validate $val/$val2 against platform_max, add the $min offset to val first. (CVE-2022-48917)

Official announcement: Please see the link for details –

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

antihackingonline.com