Memory Corruption Basics & Impact

In this post, I will go over the basics of memory corruption and it's impact/consequences.

In a computing system, different processing contexts protect their memory from others for better reliability. However, there are significant use cases for sharing memory & expect all contexts to co-operatively manage the shared memory:

• different processing contexts may explicitly share memory for inter-process communication.
• different sub-processing contexts within a single processing contexts operate in all-shared-by-default memory model for efficiency reasons. 
• different functional components within a single processing context share all the memory space of that processing context

As a result, there is a possibility of buggy code one context/component occasionally stepping into others' memory resulting in memory corruption.

Which process segments are prone to corruption?

In a linux based system, the code segments is protected with read-only page flag. So, memory in code segment can't be corrupted. However, data segment, stack segment and heap segments are prone to memory corruption.

What is the memory corruption scope of different processing contexts in linux? 

• User space: Each process has its own address space & hence they can't corrupt each others' memory. However, memory corruption is possible in the following scenarios:
• buggy code within a process can corrupt it's own stack/data segments!!
• buggy code within a process can corrupt heap memory/data structures. 
• buggy code across processes can corrupt shared memory among processes
• In multi-threaded application, each thread might corrupt others' data structures in heap or stack.
• Kernel space: In kernel space, all memory (data/stack/heap) is shared across all kernel code. Moreover, when kernel modules are added to extend functionality, the scope for memory corruption increases.
• buggy code in a kernel/kernel-thread/kernel-module can corrupt kernel's data/heap segments!! 
• buggy code in a kernel-kernel-thread/kernel-module can corrupt it's own stack or any kernel thread's stack or IRQ's stack.

Impact/Consequences/Symptoms of Memory Corruption

• Crashes(seg fault or kernel panic)
• with gibberish backtrace (stack corruption)
• .
• .
• functional failure (more dangerous & should be perceived as a security vulnerability as well)
• infinite loops (due to loop limit variables being corrupted)
• alteration in program's control flow (due to function pointers being corrupted)