CVE-2021-27562

What it actually does

CVE-2021-27562 is a memory-corruption issue in Arm Trusted Firmware-M through version 1.2 affecting calls from the Non-Secure Processing Environment into secure functions while the non-secure side is in handler mode. A local attacker with the ability to execute non-secure code can invoke secure services in an unsafe processor state and trigger outcomes including a system halt, corruption or overwrite of secure-world data, or unintended printing/disclosure of secure data. The main technical risk is compromise of the intended secure/non-secure isolation boundary on affected embedded platforms, with denial of service being the clearest CVSS-scored impact.

Why it matters to the business

Devices or products built on vulnerable Arm Trusted Firmware-M versions may be made unstable or unavailable by code running in the non-secure environment, potentially causing outages, device resets, degraded service reliability, or loss of safety/control functionality depending on the deployment. Because this vulnerability is listed in CISA KEV with a remediation due date of 2021-11-17 and exploit maturity is reported as active in the wild, remediation should be treated as overdue for any exposed or fielded affected firmware. Although the EPSS score is low and stable at about 3.1%, KEV status is a stronger urgency signal because exploitation has been observed. The supplied affected-product metadata also references googlechrome/rendertron with a fixed Git commit; organizations should validate whether that package mapping is applicable because the vulnerability description itself is for Arm Trusted Firmware-M.

How an attack unfolds

An attacker first needs a foothold that allows execution of code in the non-secure world on a device using Arm Trusted Firmware-M through 1.2. From there, the attacker triggers secure function calls while the non-secure processor context is in handler mode rather than a normal expected calling context. The vulnerable firmware mishandles this boundary condition, allowing the call path to corrupt memory or otherwise mishandle secure-world data. Depending on platform integration and enabled diagnostics, the result may be a halt or reset of the system, modification of secure data structures, or unintended printing of data that should remain confined to the secure world. In real attacks this would most often be used after initial local code execution to disrupt device operation, weaken secure-state assumptions, or assist further compromise of embedded trust functions.

How to fix it

Upgrade Arm Trusted Firmware-M to a vendor-supported version that contains the fix for this issue; versions through 1.2 should be considered vulnerable. For embedded products, this typically requires applying the silicon vendor, device OEM, RTOS, or firmware vendor update that incorporates the corrected TF-M code, then rebuilding and redeploying signed firmware images. If maintaining source forks, review and merge the upstream Arm Trusted Firmware-M fix related to secure function calls from NSPE handler mode and add regression tests for non-secure handler-mode secure-service invocation. The provided package metadata lists googlechrome/rendertron as fixed in Git commit 8951beb3890b44a479676f128eb4c77857db6d8c; if that package is part of the relevant inventory, pin or update to that commit or later, but validate the mapping because it does not match the Arm Trusted Firmware-M vulnerability description. Where immediate firmware replacement is not possible, reduce exposure by preventing untrusted non-secure code execution, disabling unnecessary secure service entry points, limiting diagnostic output that could print secure data, enabling watchdog recovery, and using platform controls that restrict interrupt/exception paths into secure calls.

How to confirm the fix worked

Confirm affectedness by inventorying firmware SBOMs, source trees, and build manifests for Arm Trusted Firmware-M versions through 1.2 or vendor forks based on those releases. Validate remediation by confirming the deployed firmware contains the upstream or vendor fix and is not built from a vulnerable TF-M baseline. On source-based builds, inspect secure service gateway and NSPE handler-mode validation logic to ensure calls from invalid non-secure handler contexts are rejected or safely handled. On devices, perform controlled regression testing that attempts secure function calls from non-secure handler-mode paths and confirm the device does not halt, reset, overwrite secure-state test data, or emit secure data through logs or serial/debug output. For the supplied rendertron package metadata, verify the deployed Git revision is 8951beb3890b44a479676f128eb4c77857db6d8c or later if that package is truly in scope.

Typical attack path

1. Gain the ability to run code in the non-secure environment of an affected Arm TrustZone-M based device or firmware image.
2. Identify that the device uses Arm Trusted Firmware-M through version 1.2 or a vendor firmware build containing the vulnerable code.
3. Force execution into a non-secure handler-mode context, such as an interrupt or exception-handling path.
4. Invoke vulnerable secure service entry points from that handler-mode context.
5. Trigger the memory-corruption condition, causing secure data overwrite, secure data output through diagnostics, or a device halt/reset.
6. Use the resulting denial of service, data exposure, or corruption to disrupt operations or support follow-on embedded-system compromise.

How to detect it

Look for signs of prior exploitation in device telemetry, firmware logs, serial console output, crash dumps, watchdog records, and secure fault logs. Useful evidence includes repeated unexpected system halts or resets following non-secure interrupt/exception handling, SecureFault/HardFault events near secure service calls, anomalous secure diagnostic output appearing on non-secure consoles, corrupted secure-world configuration/state after crashes, or repeated invocation of secure APIs from exception handlers. On products with tracing enabled, correlate non-secure handler-mode execution immediately followed by secure gateway calls and resets. For fielded devices, compare crash frequency before and after firmware updates and investigate clusters of unexplained reboots. If threat-hunting at source or binary level, identify firmware images containing Arm Trusted Firmware-M through 1.2 or forks lacking the NSPE handler-mode fix. No universal network IOC is expected because exploitation is local to the device firmware execution context and depends on platform-specific logging.

What your security team should do

• Treat this as an overdue KEV item and prioritize confirmation of exposure in firmware, embedded device, IoT, operational technology, and product security inventories.
• Identify all products, boards, SDKs, RTOS integrations, and vendor firmware images that include Arm Trusted Firmware-M through 1.2 or derived forks.
• Obtain patched firmware or source updates from Arm, silicon vendors, OEMs, or internal firmware teams and schedule signed firmware rollout for affected devices.
• If source code is maintained internally, merge the upstream fix and add tests for secure-service calls made from non-secure handler-mode contexts.
• Review crash, reset, secure fault, watchdog, and serial/debug logs for evidence of repeated unexpected faults around secure-service invocation.
• Disable or restrict debug/diagnostic channels that could expose secure data, especially on production devices.
• Where patching cannot be immediate, reduce the ability for untrusted code to execute in the non-secure world and restrict unnecessary secure service interfaces.
• Validate the anomalous googlechrome/rendertron package mapping before relying on it for remediation; if applicable, update to commit 8951beb3890b44a479676f128eb4c77857db6d8c or later.