Preface: The vulnerability described in AMD-SB-7038 is based on a general microarchitectural behavior: memory reordering and out-of-order execution. These techniques are used by all major CPU vendors (Intel, ARM, etc.) to improve performance.

Background: The bulletin describes a research paper titled “MEMORY DISORDER: Memory Re-orderings as a Timerless Side-channel.”

Key points from AMD’s disclosure:

Nature of the issue:
Researchers demonstrated that memory re-orderings in CPUs and GPUs can be exploited as a timerless side-channel attack.
This means attackers can infer activity in other processes by observing subtle memory ordering patterns—without using timing measurements.

Impact:

• Potential for covert channels (secret communication between processes).
• Possible application fingerprinting (detecting what app is running).
• No direct data corruption or privilege escalation, but information leakage risk.

Scope:

• Applies to mainstream processors, including AMD CPUs and GPUs.
• It’s informational, not an emergency patch scenario. AMD classifies it as low severity because exploitation requires local access and advanced techniques.

Vulnerability details: Please refer to the link for details –

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

AMD-SB-7038 is about information leakage via subtle ordering patterns, not about allowing other processes to access memory during waits.

The vulnerability is about memory reordering being observable as a side-channel, not about direct memory access.

Remark: The attacker doesn’t need precise timing; they can infer ordering by observing cache state or contention.

In conclusion, this is a problem common to the entire industry, not unique to AMD. It is not due to any unique defects in its hardware.

Published: 2025-10-24

Preface: The Australian government has utilized Bouncy Castle cryptography APIs. Specifically, the Australian Government’s AUSKey project, which was a system for securely accessing government online services, used the Bouncy Castle libraries as its basis for Java cryptography.

Bouncy Castle is a widely-used open-source cryptographic API available for Java and C#, developed and maintained by the Legion of the Bouncy Castle Inc., a registered Australian charitable organization. It is known for its FIPS-certified modules, which meet a recognized government standard for cryptographic modules.

Background: The objective of the Bouncy Castle cryptography project is to provide a comprehensive set of open-source APIs for Java and C# that implement cryptographic algorithms and protocols to build secure applications. It aims to offer a wide range of security features, including those for public key infrastructure, digital signatures, authentication, secure communication, and FIPS-certified cryptographic modules for applications requiring a high level of compliance. 

While the javax.crypto.Cipher class and the JCA/JCE frameworks provide the core for cryptographic operations in Java, the Bouncy Castle cryptography library is often needed for below reasons: 

Extended Algorithm Support: Bouncy Castle offers a broader range of cryptographic algorithms and modes compared to the default JCE providers, including advanced algorithms like elliptic curve cryptography (ECC) which may not be fully or natively supported by the standard JCE.

Implementation of Emerging Standards: Bouncy Castle frequently incorporates implementations of newer cryptographic standards and protocols before they are fully integrated into the standard JCE, allowing developers to utilize cutting-edge security features.

CVE details: Further issues have shown up in high-core environments with Java 21 and BC-FJA 2.1.1. It appears under very high loads the scheduling of the disposal thread is such that it only gets called rarely, or at least not soon enough. The issue has been fixed by introducing the use of reachability-fencing. This available in Java 9 and later, so Java 8 is still using the disposal daemon as before has been changed to reduce friction (synchronized has been introduced where some friction is still required). A new property has also been added “org.bouncycastle.native.cleanup_priority” which can be set to “min”, “normal”, or “high” (default “min”) in case disposal thread scheduling will be beneficial for Java 8 as well.

Official announcement: Please see the link for details –

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

https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902025%E2%80%9012194

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