Advisory: Miscompilation in cortex-m-rt 0.7.1 and 0.7.2

[adamgreig]

Advisory Notice: cortex-m-rt

Summary

Version 0.7.1 of the cortex-m-rt crate introduced a regression causing the stack to NOT be eight-byte aligned prior to calling main (or any other specified entrypoint), violating the stack ABI of AAPCS32, the default ABI used by all Cortex-M targets. This regression is also present in version 0.7.2 of the cortex-m-rt crate.

This regression can cause certain compiler optimizations (which assume the eight-byte alignment) to produce incorrect behavior at runtime. This incorrect behavior has been observed in real-world applications.

It is advised that ALL users of v0.7.1 and v0.7.2 of the cortex-m-rt crate update to the latest version (v0.7.3), AS SOON AS POSSIBLE. Users of v0.7.0 and prior versions of cortex-m-rt are not affected by this regression.

It will be necessary to rebuild all affected firmware binaries, and flash or deploy the new firmware binaries to affected devices.

Users of probe-run v0.3.6 and earlier will see a warning reported when stack unwinding goes past the main function, see here for details. This is due to probe-run relying on behavior of cortex-m-rt that has been changed to fix this issue. Unwinding and other probe-run functionality is unaffected apart from the new warning message.

Technical details

Details regarding the requirements of AAPCS32 can be found at Arm's documentation site.

Details on the changes can be found in the cortex-m-rt#467 PR, with more discussion in cortex-m-rt#463.

The regression was introduced in this commit.

Potentially Affected Configurations

• Any versions of rustc, including stable and nightly releases
• AND Any of the following Cortex-M targets:
  • thumbv6m-none-eabi
  • thumbv7m-none-eabi
  • thumbv7em-none-eabi
  • thumbv7em-none-eabihf
  • thumbv8m.base-none-eabi
  • thumbv8m.main-none-eabi
  • thumbv8m.main-none-eabihf
• AND Any of the following versions of cortex-m-rt:
  • v0.7.1
  • v0.7.2

For miscompilation to occur, specific compiler optimisations must have taken place. It is not trivial to determine if they have, so if you have a potentially affected configuration you are strongly advised to upgrade to 0.7.3.

Any other configuration, including other CPU architectures (e.g. RISC-V, MSP430, AVR) and firmware projects not using the cortex-m-rt crate are NOT affected.

Determining if you may be affected

Run the following command in your embedded project:

cargo tree -p cortex-m-rt --depth=0

Affected users will see one of the following outputs:

cortex-m-rt v0.7.1

# OR

cortex-m-rt v0.7.2

If present, the Cargo.lock file may also be inspected to verify:

grep -i --after=1 'name = "cortex-m-rt"' ./Cargo.lock

Affected users will see one of the following outputs:

name = "cortex-m-rt"
version = "0.7.1"

# OR

name = "cortex-m-rt"
version = "0.7.2"

Applying the update

The cortex-m-rt package can be updated using the cargo-update command.

cargo update -p cortex-m-rt
    Updating crates.io index
    Updating cortex-m-rt v0.7.2 -> v0.7.3

You can also manually edit your Cargo.toml to apply this update:

[dependencies]

# before
cortex-m-rt = "0.7"

# after
cortex-m-rt = "0.7.3"

After updating, verify that version 0.7.3 (or later) of cortex-m-rt crate is now in use, using the procedure described in the "Determining if you are affected" section above.

It will be necessary to rebuild all affected firmware binaries, and flash or deploy the new firmware binaries to affected devices.

Contact

If you have any questions regarding this notice, including how to check if you are affected, or how to apply the update, please start a discussion.

Credits

Thanks to @jamesmunns for writing this advisory and helping research the impact and solutions, @Dirbaio for developing the fix, @peter9477 for first discovering it, and everyone else on the Rust Embedded Matrix who helped investigate.