Fixing NULL Pointer Dereference in eMMC Memory Allocation: A Deep Dive

Introduction

Memory allocation failures are one of the oldest and most persistent classes of bugs in C and C++ programming. Yet, despite decades of awareness, unchecked malloc and calloc return values continue to appear in production codebases — especially in embedded systems and low-level storage drivers where developers are often focused on performance and functionality over defensive programming.

This post covers a high-severity NULL pointer dereference vulnerability (V-003) that was recently discovered and patched in src/emmc.c and src/devtools.c. The vulnerability allowed an attacker who could supply a crafted eMMC image to deliberately crash the host process by triggering a NULL pointer dereference through manipulated partition size fields.

If you write C code that handles untrusted input — especially in storage drivers, file parsers, or embedded firmware — this one's for you.

The Vulnerability Explained

What Is a NULL Pointer Dereference?

In C, malloc() and calloc() return a pointer to newly allocated heap memory. But they can also return NULL — a special sentinel value indicating that the allocation failed. This happens when:

• The system is under memory pressure (not enough free heap)
• The requested size is 0 (implementation-defined, but often returns NULL)
• The requested size is extremely large (overflow or exceeds available memory)

When a program receives NULL back from an allocator and then tries to read from or write to that pointer, it triggers a NULL pointer dereference. In user-space applications, this typically causes a segmentation fault and process crash. In kernel or embedded contexts, the consequences can be even more severe.

The Vulnerable Code Pattern

The vulnerable code in emmc.c followed a pattern like this:

// VULNERABLE: No NULL check after allocation
uint8_t *partition_buffer = malloc(partition_size);
memcpy(partition_buffer, source_data, partition_size);  // CRASH if malloc returned NULL

Or with calloc:

// VULNERABLE: No NULL check after calloc
struct partition_entry *entries = calloc(num_entries, sizeof(struct partition_entry));
entries[0].start_lba = read_lba();  // CRASH if calloc returned NULL

At first glance, these look harmless — especially in development environments where memory is plentiful. But the danger emerges when the size parameter is attacker-controlled.

The Attack Vector

Here's where it gets interesting. The partition_size variable in emmc.c was derived from fields in the eMMC partition table — a data structure read directly from the eMMC image. Consider this attack scenario:

Step 1: An attacker crafts a malicious eMMC image with an intentionally oversized partition size field. For example, setting partition_size to 0xFFFFFFFF (4 GB) or even 0x0.

Step 2: The host system parses this image. The code calls malloc(0xFFFFFFFF), which fails on most systems and returns NULL.

Step 3: The code proceeds without checking the return value, immediately dereferencing the NULL pointer.

Step 4: The host process crashes — a classic Denial of Service (DoS) via a crafted input file.

Attacker crafts eMMC image
         │
         ▼
  partition_size = 0xFFFFFFFF  (from malicious image header)
         │
         ▼
  malloc(0xFFFFFFFF) → returns NULL
         │
         ▼
  memcpy(NULL, src, size) → SIGSEGV / process crash
         │
         ▼
  Host process terminated (DoS)

Real-World Impact

• Denial of Service: Any system that processes untrusted eMMC images (imaging tools, forensic software, emulators, provisioning systems) could be crashed on demand.
• Potential for Further Exploitation: In some architectures and contexts, NULL pointer dereferences can be escalated beyond a simple crash. Historically, on Linux kernels before mmap_min_addr protections, an attacker could map memory at address 0 and turn a NULL dereference into arbitrary code execution.
• Supply Chain Risk: Embedded firmware provisioning tools that process eMMC images from third-party vendors are particularly exposed.

The Fix

What Changed

The fix is conceptually straightforward but critically important: every call to malloc and calloc now has its return value checked before use. If allocation fails, the code handles the error gracefully — typically by logging the failure and returning an error code — rather than proceeding with a NULL pointer.

Before (Vulnerable Pattern)

// src/emmc.c - BEFORE FIX
static int parse_partition_table(emmc_image_t *img, uint32_t partition_size) {
    uint8_t *buffer = malloc(partition_size);
    // No NULL check — if malloc fails, buffer is NULL
    memset(buffer, 0, partition_size);  // Undefined behavior / crash

    read_partition_data(img, buffer, partition_size);
    // ... processing ...

    free(buffer);
    return 0;
}

// src/devtools.c - BEFORE FIX
partition_entry_t *entries = calloc(entry_count, sizeof(partition_entry_t));
// No NULL check
for (int i = 0; i < entry_count; i++) {
    entries[i].flags = DEFAULT_FLAGS;  // Crash if calloc returned NULL
}

After (Fixed Pattern)

// src/emmc.c - AFTER FIX
static int parse_partition_table(emmc_image_t *img, uint32_t partition_size) {
    // Validate size before allocation
    if (partition_size == 0 || partition_size > MAX_PARTITION_SIZE) {
        log_error("Invalid partition size: %u", partition_size);
        return -EINVAL;
    }

    uint8_t *buffer = malloc(partition_size);
    if (buffer == NULL) {  // ✅ NULL check added
        log_error("Failed to allocate %u bytes for partition buffer", partition_size);
        return -ENOMEM;
    }

    memset(buffer, 0, partition_size);
    read_partition_data(img, buffer, partition_size);
    // ... processing ...

    free(buffer);
    return 0;
}

// src/devtools.c - AFTER FIX
partition_entry_t *entries = calloc(entry_count, sizeof(partition_entry_t));
if (entries == NULL) {  // ✅ NULL check added
    log_error("Failed to allocate partition entries table");
    return -ENOMEM;
}
for (int i = 0; i < entry_count; i++) {
    entries[i].flags = DEFAULT_FLAGS;  // Safe — entries is guaranteed non-NULL
}

Why This Fix Works

The fix addresses the vulnerability at two levels:

1. Input Validation: By checking partition_size against a reasonable maximum (MAX_PARTITION_SIZE) before even attempting allocation, the code rejects obviously malicious inputs early. This is a classic example of the "validate before use" principle.

2. Allocation Failure Handling: By checking the return value of malloc/calloc and returning an error code instead of proceeding, the code converts a potential crash into a controlled, recoverable error. The caller can log it, report it, and continue operating.

Prevention & Best Practices

1. Always Check Allocator Return Values

This cannot be overstated. In C, there is no automatic exception for failed allocations. Make it a rule:

// ✅ The correct pattern — always
void *ptr = malloc(size);
if (ptr == NULL) {
    // Handle error
    return ERROR_CODE;
}

Some teams use wrapper functions to enforce this:

// Safe malloc wrapper that aborts or returns error on failure
void *safe_malloc(size_t size) {
    if (size == 0) {
        return NULL;  // Explicit handling of zero-size
    }
    void *ptr = malloc(size);
    if (ptr == NULL) {
        // Log, alert, or abort depending on context
        abort();  // For critical embedded systems where partial state is dangerous
    }
    return ptr;
}

⚠️ Note: Using abort() in a wrapper is appropriate for some embedded contexts but not for servers or user-facing applications where graceful degradation is preferred.

2. Validate Sizes from Untrusted Sources

Any size value derived from external input — a file, network packet, hardware register, or user input — must be validated before use in an allocation:

#define MAX_SAFE_PARTITION_SIZE (256 * 1024 * 1024)  // 256 MB upper bound

if (partition_size > MAX_SAFE_PARTITION_SIZE) {
    return -EINVAL;  // Reject before allocation attempt
}

3. Check for Integer Overflow in Size Calculations

A related vulnerability: when computing allocation sizes with multiplication (e.g., count * element_size), integer overflow can wrap the value to a small number, causing under-allocation followed by a heap buffer overflow:

// DANGEROUS: integer overflow possible
size_t total = count * sizeof(struct entry);  // Could overflow!
void *buf = malloc(total);

// SAFE: use checked multiplication
if (count > SIZE_MAX / sizeof(struct entry)) {
    return -EINVAL;  // Would overflow
}
size_t total = count * sizeof(struct entry);
void *buf = malloc(total);

On modern systems, consider using reallocarray() or similar checked-multiplication allocators.

4. Use Static Analysis Tools

Several tools can automatically detect unchecked allocator return values:

Add these to your CI/CD pipeline:

# Example: GitHub Actions with cppcheck
- name: Run cppcheck
  run: cppcheck --enable=all --error-exitcode=1 src/

5. Adopt Safer Memory Patterns Where Possible

In new code, consider patterns that reduce the risk:

• Use arena/pool allocators for fixed-size objects where allocation failure can be detected once at pool creation time.
• Pre-allocate buffers of maximum expected size at startup when dealing with bounded inputs.
• Consider Rust or C++ with RAII for new components where memory safety is critical — though this isn't always feasible in embedded contexts.

Relevant Security Standards

• CWE-476: NULL Pointer Dereference — directly applicable here
• CWE-252: Unchecked Return Value — the root cause
• CWE-789: Memory Allocation with Excessive Size Value — relevant to the attack vector
• CERT C Rule MEM32-C: Detect and handle memory allocation errors
• OWASP: Denial of Service: General DoS attack patterns

Conclusion

The NULL pointer dereference vulnerability in emmc.c is a textbook example of how a simple, one-line oversight — failing to check a malloc return value — can open the door to denial-of-service attacks when the size parameter comes from untrusted input. The fix is equally straightforward: validate inputs, check return values, and handle errors gracefully.

Key Takeaways

• ✅ Always check the return value of malloc, calloc, realloc, and similar allocators
• ✅ Validate sizes derived from external data before using them in allocations
• ✅ Guard against integer overflow in size calculations
• ✅ Use static analysis tools in CI/CD to catch these patterns automatically
• ✅ Treat allocation failure as a real, exploitable scenario — not just a theoretical edge case

Memory safety in C requires constant vigilance. The good news is that tools, patterns, and a security-first mindset can catch the vast majority of these issues before they reach production. Make NULL checks a reflex, not an afterthought.

This vulnerability was identified and fixed as part of an automated security scanning process. Kudos to the team for the quick turnaround on the fix.

Have questions about memory safety in embedded C? Drop them in the comments below.