Introduction to Memory Safety Bugs

A memory safety bug is a type of software defect that occurs when a program accesses memory in unsafe or unintended ways. These software bugs usually arise in low-level languages like C and C++ where the programmer is responsible for managing memory directly (allocation, deallocation, and bounds checking).

Key Types of Memory Safety Bugs

Buffer Overflows / Overreads
The C program reads or writes past the allocated boundary of a buffer (array/string).
Example: Writing 11 characters into a 10-character buffer.
Use-After-Free
A program continues to access memory after it has been freed. The memory might now hold different data or be used by another part of the program.
Dangling Pointers
A pointer still refers to memory that is no longer valid. Using it can cause crashes or unpredictable behaviour.
Uninitialized Memory Use
A program reads memory that was never initialized. Could leak sensitive information or cause incorrect behaviour.
Double Free
Memory is freed more than once, potentially corrupting memory allocation structures.

Why Memory Safety Bugs Matter

Memory safety bugs are very common in systems programming where performance is prioritized over automatic memory protection.

Memory safety bugs can lead to :

Safety vulnerabilities

Attackers can exploit them to read sensitive data (as in Heartbleed – See this article for a deep dive on Heartbleed), execute arbitrary code, or crash systems.

Stability Issues

Crashes, data corruption, or unpredictable program behaviour. See this article that describes why the CHERIoT philosophy is designed to prevent things like the CrowdStrike disaster.

Prevention Approaches

Use ICENI microcontrollers: Utilise 100% memory safe hardware. With its hardware-enforced CHERI technology, memory cannot be read outside of authorized bounds, and the rest of the memory contents stay protected.
Write in ‘safe’ programming languages: Rust, Java, Python, Go — they handle memory automatically or enforce stricter rules but often at the expense of performance, but it is not always feasible to re-write your production tested C/C++ code into these languages. This article explains why combining a CHERI-based MCU and safe language is the best solution https://cheriot.org/cheri/myths/2024/08/28/cheri-myths-safe-languages.html
Utilise compiler protections: Stack canaries, address space layout randomization (ASLR).
Use runtime checks: Tools like Valgrind, AddressSanitizer detect violations, but they can be slow and cannot guarantee to identify run time errors
Thorough Code Review and Fuzzing: Help catch memory misuse during development but this can be time consuming and costly for catching errors that can easily be found with CHERI technology out of the box.

Summary

With ICENI devices and it’s hardware-enforced CHERI memory safety technology, memory cannot be read outside of the authorized and expected bounds; the rest of the memory is protected and its contents stay safe.

Find out more about ICENI – Contact Us now