Memory Safety on guy@secdev.uk

Memory Safety Without Rust: Defensive C and C++ Patterns

Sat, 14 Mar 2026 00:00:00 +0000

I hear “just rewrite it in Rust” a lot these days, and while Rust’s ownership model genuinely does eliminate entire classes of memory safety bugs at compile time, that advice ignores reality. The vast majority of systems code – operating systems, embedded firmware, database engines, network stacks – is written in C and C++ and will remain so for decades. Rewriting is not always an option. So I wanted to dig into the defensive patterns, compiler features, and runtime tools that bring memory safety closer to C and C++ codebases without a language migration. What I found is that while none of these approaches match Rust’s compile-time guarantees, the combination of them makes a real difference.

C++ Security: Smart Pointers Aren't Always Smart Enough

Sat, 08 Nov 2025 00:00:00 +0000

The more I dug into C++ codebases, the more I noticed a recurring assumption: developers who think that switching to smart pointers and STL containers means they’re safe from memory bugs. C++ adds RAII, smart pointers, containers, and type-safe abstractions on top of C’s manual memory model, and these features genuinely eliminate many of C’s most common vulnerabilities, std::string prevents buffer overflows, std::unique_ptr prevents memory leaks, and std::vector provides bounds-checked access via .at(). But C++ also introduces new attack surfaces that turn out to be even trickier to spot: dangling references from moved-from objects, iterator invalidation, implicit conversions in template code, and the false sense of security that comes from using “safe” abstractions incorrectly. In this post, I want to cover the C++-specific anti-patterns that survive code review because they look correct to developers who trust the standard library.

C Security: Manual Memory Management and Its Consequences

Sat, 25 Oct 2025 00:00:00 +0000

C gives you direct control over memory allocation, pointer arithmetic, and hardware interaction. I respect that. But that control comes with absolutely no safety net: no bounds checking, no garbage collection, no type safety beyond what you enforce manually. Every buffer overflow, use-after-free, double-free, format string vulnerability, and null pointer dereference in C is a direct consequence of this design. C remains the language of operating systems, embedded systems, and performance-critical libraries, so its security pitfalls affect every layer of the software stack. When I started digging into the patterns behind C vulnerabilities, the same shapes kept appearing, from the textbook strcpy overflow to the subtle integer promotion that bypasses a bounds check. Let me walk through them.

Rust Security: When unsafe Breaks the Promise

Sat, 11 Oct 2025 00:00:00 +0000

I love Rust. I genuinely do. Its ownership system, borrow checker, and type system wipe out entire classes of vulnerabilities at compile time, use-after-free, double-free, data races, null pointer dereferences, buffer overflows. But here’s the thing: Rust gives you an escape hatch called unsafe, and when it’s used incorrectly, it reintroduces every single vulnerability that Rust was designed to prevent. The more I dug into real-world Rust codebases, the more I found this happening. Beyond unsafe, Rust has its own quirky set of security pitfalls: integer overflow behaviour that differs between debug and release builds, FFI boundaries that trust C code unconditionally, and logic errors that the type system simply cannot catch. In this post, I want to walk through the Rust-specific anti-patterns that break the safety promise.

Null Pointer Dereference

Sat, 19 Jul 2025 00:00:00 +0000

Null pointer dereference (CWE-476) is one of those bugs that shows up across every language, and the more I researched it for this post, the more I was struck by how much damage it can do depending on context. The consequences vary dramatically: C programs crash with a segfault (or worse, the kernel maps page zero and an attacker gets code execution), C++ invokes undefined behaviour that the compiler may optimise into literally anything, Go panics with a nil pointer dereference that kills the goroutine or the whole program, and Java throws a NullPointerException that can crash the app or leak stack traces to an attacker. MITRE ranks CWE-476 consistently in the top 25 most dangerous software weaknesses, and digging into the CVE data, that ranking is well deserved. I want to walk through C, C++, Go, and Java here, from the obvious unchecked malloc return to the subtle nil interface trap in Go and the conditional path where null silently propagates through multiple function calls.

Use After Free

Sat, 05 Jul 2025 00:00:00 +0000

Use-after-free (CWE-416) is one of those bug classes that I wanted to understand deeply because it keeps showing up at the root of high-profile exploits. It occurs when a program continues to use a pointer after the memory it references has been freed. The freed memory may be reallocated for a different purpose, and the dangling pointer now reads or writes data that belongs to a completely different object. Attackers exploit this by controlling what gets allocated into the freed slot, replacing a data buffer with a crafted object that contains a function pointer, then triggering the dangling pointer to call through it. Reading through CVE databases, use-after-free is at the root of hundreds of browser exploits, kernel privilege escalations, and server compromises. This post covers C and C++, from the obvious free-then-use to the subtle shared-pointer aliasing and callback registration patterns that can evade expert review.

Out-of-Bounds Writes

Sat, 21 Jun 2025 00:00:00 +0000

Out-of-bounds writes (CWE-787) are the single most dangerous class of memory corruption vulnerabilities on the SANS/CWE Top 25, and they’ve held that position for years. The reason is clear once you dig into the mechanics: writing past the end of a buffer can overwrite return addresses, function pointers, vtable entries, and adjacent heap metadata, giving attackers arbitrary code execution. Unlike higher-level languages where the runtime catches array index violations, C and C++ silently corrupt memory, and the consequences may not manifest until thousands of instructions later. Even Rust, with its ownership model, is vulnerable when unsafe blocks bypass the borrow checker. In this post I’ll dissect out-of-bounds writes in C, C++, and Rust, from the classic strcpy overflow to the subtle off-by-one in pointer arithmetic that can survive expert review.