A feature, API, or function does not perform according to its specification.

Primary

Architecture and Design

Implementation

Operation

Other
Quality Degradation
Varies by Context

The provided code is extracted from the Control and Status Register (CSR), csr_regfile, module within the Hack@DAC'21 OpenPiton System-on-Chip (SoC). This module is designed to implement CSR registers in accordance with the RISC-V specification. The mie (machine interrupt enable) register is a 64-bit register [REF-1384], where bits correspond to different interrupt sources. As the name suggests, mie is a machine-level register that determines which interrupts are enabled. Note that in the example below the mie_q and mie_d registers represent the conceptual mie reigster in the RISC-V specification. The mie_d register is the value to be stored in the mie register while the mie_q register holds the current value of the mie register [REF-1385].
The mideleg (machine interrupt delegation) register, also 64-bit wide, enables the delegation of specific interrupt sources from machine privilege mode to lower privilege levels. By setting specific bits in the mideleg register, the handling of certain interrupts can be delegated to lower privilege levels without engaging the machine-level privilege mode. For example, in supervisor mode, the mie register is limited to a specific register called the sie (supervisor interrupt enable) register. If delegated, an interrupt becomes visible in the sip (supervisor interrupt pending) register and can be enabled or blocked using the sie register. If no delegation occurs, the related bits in sip and sie are set to zero.
The sie register value is computed based on the current value of mie register, i.e., mie_q, and the mideleg register.

module csr_regfile #(...)(...);
...
// ---------------------------
// CSR Write and update logic
// ---------------------------
...

if (csr_we) begin

unique case (csr_addr.address)
...

riscv::CSR_SIE: begin

// the mideleg makes sure only delegate-able register
//(and therefore also only implemented registers) are written
mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q) | utval_q;

end
...

endcase

end

endmodule

The above code snippet illustrates an instance of a vulnerable implementation of the sie register update logic, where users can tamper with the mie_d register value through the utval (user trap value) register. This behavior violates the RISC-V specification.
The code shows that the value of utval, among other signals, is used in updating the mie_d value within the sie update logic. While utval is a register accessible to users, it should not influence or compromise the integrity of sie. Through manipulation of the utval register, it becomes feasible to manipulate the sie register's value. This opens the door for potential attacks, as an adversary can gain control over or corrupt the sie value. Consequently, such manipulation empowers an attacker to enable or disable critical supervisor-level interrupts, resulting in various security risks such as privilege escalation or denial-of-service attacks.
A fix to this issue is to remove the utval from the right-hand side of the assignment. That is the value of the mie_d should be updated as shown in the good code example [REF-1386].

module csr_regfile #(...)(...);
...
// ---------------------------
// CSR Write and update logic
// ---------------------------
...

if (csr_we) begin

unique case (csr_addr.address)
...

riscv::CSR_SIE: begin

// the mideleg makes sure only delegate-able register
//(and therefore also only implemented registers) are written
mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q);

end
...

endcase

end

endmodule

CVE-2003-0187
Program uses large timeouts on unconfirmed connections resulting from inconsistency in linked lists implementations.
https://www.cve.org/CVERecord?id=CVE-2003-0187

CVE-2003-0465
"strncpy" in Linux kernel acts different than libc on x86, leading to expected behavior difference - sort of a multiple interpretation error?
https://www.cve.org/CVERecord?id=CVE-2003-0465

CVE-2005-3265
Buffer overflow in product stems the use of a third party library function that is expected to have internal protection against overflows, but doesn't.
https://www.cve.org/CVERecord?id=CVE-2005-3265

Expected behavior violation

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

The behavior of an application that is not consistent with the expectations of the developer may lead to incorrect use of the software.

PLOVER
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Relationships, Other_Notes, Taxonomy_Mappings

CWE Content Team
MITRE
2009-10-29
updated Other_Notes, Relevant_Properties, Theoretical_Notes

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2011-06-27
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated Relationships

CWE Content Team
MITRE
2014-07-30
updated Relationships

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms, Relevant_Properties

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2020-08-20
updated Description, Observed_Examples, Theoretical_Notes

CWE Content Team
MITRE
2023-01-31
updated Applicable_Platforms, Relationships

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2023-10-26
updated Observed_Examples

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Demonstrative_Examples, References

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated Relationships

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities

Chen Chen, Rahul Kande, Jeyavijayan Rajendran
Texas A&M University
2023-06-21
suggested demonstrative example

Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza Sadeghi
Technical University of Darmstadt
2023-06-21
suggested demonstrative example