CWE-1310: Missing Ability to Patch ROM Code | Glexia
CWE-1310 (Missing Ability to Patch ROM Code) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE ATT&CK context.
Glexia's Take · Automated analysis
CWE-1310: Missing Ability to Patch ROM Code
Missing Ability to Patch ROM Code represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Other: Varies by Context,Reduce Maintainability: When the system is unable to be patched, it can be left in a vulnerable state.
Developer Pattern
CWE-1310 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-1310, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-1310: Missing Ability to Patch ROM Code
Missing an ability to patch ROM code may leave a System or System-on-Chip (SoC) in a vulnerable state.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- ROM does not have built-in application-programming interfaces (APIs) to patch if the code is vulnerable. Implement mechanisms to patch the vulnerable ROM code.
- The example code is taken from the SoC peripheral wrapper inside the buggy OpenPiton SoC of HACK@DAC'21. The wrapper is used for connecting the communications between SoC peripherals, such as crypto-engines, direct memory access (DMA), reset controllers, JTAG, etc. The secure implementation of the SoC wrapper should allow users to boot from a ROM for Linux (i_bootrom_linux) or from a patchable ROM (i_bootrom_patch) if the Linux bootrom has security or functional issues.The example code is taken from the SoC peripheral wrapper inside the buggy OpenPiton SoC of HACK@DAC'21. The wrapper is used for connecting the communications between SoC peripherals, such as crypto-engines, direct memory access (DMA), reset controllers, JTAG, etc. The secure implementation of the SoC wrapper should allow users to boot from a ROM for Linux (i_bootrom_linux) or from a patchable ROM (i_bootrom_patch) if the Linux bootrom has security or functional issues.
Remediation
- Architecture and Design,Implementation: Secure patch support to allow ROM code to be patched on the next boot.
- Architecture and Design,Implementation: Support patches that can be programmed in-field or during manufacturing through hardware fuses. This feature can be used for limited patching of devices after shipping, or for the next batch of silicon devices manufactured, without changing the full device ROM.
Detection
- Code review
- SAST
- DAST
- Focused regression tests
Mappings
Related CVEs, CWEs, and ATT&CK context
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.