Skip to main content
CVE-2025-56301VulnerabilityPublished Updated

CVE-2025-56301: n/a

Source CVE Database V5

0

Not known to be exploited · CVSS 7.5 High.

Data as of 25 Oct 2026, 19:02 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.6% chance of exploitation in 30 days – higher than 50% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 30 Sep 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.

What to do

AI-suggested

Since no official patches are currently available, European organizations should implement the following specific mitigations: 1) Conduct an inventory to identify all systems using the Chipsalliance Rocket-Chip processor, focusing on embedded and specialized devices. 2) Isolate vulnerable devices from untrusted networks to reduce exposure to remote exploitation. 3) Implement strict network segmentation and firewall rules to limit access to devices running Rocket-Chip processors. 4) Monitor system logs and exception handling events for anomalies indicative of corrupted trap behavior or unexpected Instruction Access Faults. 5) Engage with hardware vendors and Chipsalliance for updates or firmware patches addressing this vulnerability. 6) For new deployments, consider alternative processor designs until the vulnerability is resolved. 7) Develop incident response plans specifically addressing potential denial of service scenarios caused by this flaw. 8) Apply hardware-level mitigations if available, such as disabling or restricting MRET execution contexts where feasible. These targeted actions go beyond generic advice by focusing on network isolation, monitoring, and vendor engagement specific to the Rocket-Chip environment.

Description

An issue was discovered in Chipsalliance Rocket-Chip commit f517abbf41abb65cea37421d3559f9739efd00a9 (2025-01-29) allowing attackers to corrupt exception handling and privilege state transitions via a flawed interaction between exception handling and MRET return mechanisms in the CSR logic when an exception is triggered during MRET execution. The Control and Status Register (CSR) logic has a flawed interaction between exception handling and exception return (MRET) mechanisms which can cause faulty trap behavior. When the MRET instruction is executed in machine mode without being in an exception state, an Instruction Access Fault may be triggered. This results in both the exception handling logic and the exception return logic activating simultaneously, leading to conflicting updates to the control and status registers.

References

Community reviews

Loading reviews…