ROP has a practical limitation. Building a useful ROP chain often means hunting for enough gadgets to manipulate registers one at a time: pop this into a register, load that from memory, perform an arithmetic operation, then chain the next piece. If the binary is small, or the available gadgets are limited, constructing complex machine state from scratch is slow and tedious.
But Linux already has a mechanism that can restore a large portion of a process's execution state in a single operation. It was designed for a completely different purpose. And if an attacker can influence the state being restored, that mechanism becomes one of the most powerful control-flow primitives on the platform.
That mechanism is signal return.
What a Linux Signal Actually Is
A process executing on Linux normally runs uninterrupted. The CPU fetches instructions, executes them, advances the instruction pointer. But the kernel sometimes needs to notify the process about an event: a timer expired, the user pressed Ctrl-C, the process accessed invalid memory, another process sent it a signal.
Linux delivers this notification through signals. When the kernel determines that a process should receive a signal, it interrupts the process and, if one is configured, redirects execution to a signal handler: a function the process registered to handle that specific signal.
Common signals include SIGINT (interactive interrupt), SIGSEGV (segmentation fault), SIGTERM (termination request), and SIGALRM (timer expiry). A process can install custom handlers for most of them.
The basic flow seems simple enough:
Normal execution
↓
Signal arrives
↓
Execute signal handler
↓
Continue where execution was interrupted
But look at that last line carefully. After the handler finishes, execution has to continue exactly where it was interrupted. Not approximately. Not nearby. The process needs to resume as if nothing happened.
That means the kernel needs to remember a complete picture of what the CPU was doing when the signal arrived.
What the Kernel Has to Preserve
A running process is more than just a sequence of instructions. At any moment, the CPU holds state across many components: the instruction pointer that says which instruction is next, the stack pointer that tracks the top of the stack, general-purpose registers holding computed values or pointers, flags that reflect the results of recent comparisons, and various architecture-specific components.
When a signal arrives and the kernel redirects execution to the handler, all of that state is temporarily irrelevant to the handler. The handler runs its own code, using its own stack and registers. But when the handler returns, everything needs to be restored to what it was.
The kernel therefore saves the interrupted execution context before transferring control to the handler:
Normal execution
↓
Signal arrives
↓
Kernel saves full execution context
↓
Signal handler executes
↓
Signal return mechanism invoked
↓
Kernel restores saved execution context
↓
Process resumes exactly where it was
This is not just saving a return address. It is saving enough CPU state to recreate the precise execution environment that existed at the moment of interruption. The exact contents depend on the CPU architecture and the Linux ABI for that architecture, but the goal is the same: a complete snapshot.
The Signal Frame
The data structure that holds this saved state is called a signal frame.
On Linux, when a signal is delivered, the kernel pushes information representing the interrupted execution context onto the process's user-space stack. The signal handler runs in this modified stack environment. When the handler finishes, a mechanism exists to use that frame to restore the original context.
The signal frame contains representations of things like the saved instruction pointer, stack pointer, general-purpose registers, processor flags, and other architecture-specific state. The exact layout is defined by the architecture's ABI and differs meaningfully between architectures. x86, x86-64, ARM, and RISC-V each have their own representations.
The important conceptual point: the signal frame is not just a return address. It is a structured representation of the process's full CPU context. The kernel reads it to know where to restore execution, what values the registers should hold, and what processor state to reconstruct.
This is the object that makes signal return so powerful.
How Signal Return Works
After a signal handler finishes executing, the process needs to invoke the signal-return mechanism to restore context. On Linux, this involves sigreturn or rt_sigreturn, depending on the signal type and architecture.
These are not ordinary application functions you call like printf. They are part of the operating system's signal-handling machinery. On many architectures, the kernel sets up a small piece of code in a region the process can execute, called the signal trampoline, which the handler returns to. That trampoline code executes the appropriate sigreturn system call.
When sigreturn (or rt_sigreturn) is invoked, the kernel reads the signal frame from the process's stack and restores the CPU state it describes. Instruction pointer, stack pointer, general-purpose registers, flags, all of it. Execution then continues from the instruction the CPU was about to execute when the signal arrived.
This is the bridge to SROP.
The Realization
Here is the question that changes the entire picture:
The signal-return mechanism restores CPU state from a signal frame that lives on the process's stack. What if an attacker can control the contents of that frame?
Traditional ROP builds up machine state incrementally. A gadget pops a value from the stack into a register. Another gadget moves data. Another performs an operation. If you need to set ten registers to specific values, you might need ten or more gadgets, each carefully arranged on a controlled stack.
Signal return works differently. When sigreturn or rt_sigreturn executes, the kernel takes the signal frame and restores a large portion of CPU state from it at once. The instruction pointer goes to where the frame says. The stack pointer moves to what the frame says. The general-purpose registers take the values the frame contains.
If an attacker can arrange a controlled signal frame on the stack and cause sigreturn to execute, they can establish much of the CPU's execution state in a single operation, directing execution to a chosen address, with registers holding chosen values, with the stack pointer set to a chosen location.
That is the core of Sigreturn-Oriented Programming.
What SROP Actually Is
Sigreturn-Oriented Programming (SROP) is a code-reuse technique that abuses the signal-return mechanism to manipulate execution state.
The conceptual sequence is:
Attacker gains control-flow influence
↓
Arrange a controlled signal frame on the stack
↓
Cause sigreturn / rt_sigreturn to execute
↓
Kernel restores execution context from the controlled frame
↓
CPU state reflects the attacker's chosen values
↓
Execution continues from attacker-chosen address
The attacker is not injecting new executable code. They are not even primarily relying on a chain of existing gadgets. They are abusing a mechanism that exists to restore interrupted execution, by preparing the structure that mechanism reads.
The availability of the technique depends on architecture and ABI, on the binary and available primitives, and on whether the attacker can construct and position a valid-enough signal frame. It is not a property of every memory-corruption vulnerability. It is a technique available in certain circumstances where the right primitives are accessible.
Why SROP Differs From ROP
It is worth being precise about how these techniques differ, because the distinction is not just cosmetic.
ROP chains existing instruction sequences. The attacker controls which sequences execute and in what order by controlling return addresses. To place a specific value in a register, they look for a gadget that pops into that register. To set multiple registers, they chain multiple gadgets. The state is built incrementally, gadget by gadget.
SROP uses a different primitive entirely. Rather than incrementally building state through a sequence of gadgets, it causes the kernel to restore a large prepared execution context at once. The mechanism is not "gadget ending in RET." The mechanism is a legitimate operating-system call that was designed for context restoration.
Conceptually:
ROP:
Control execution
↓
Find usable gadgets
↓
Chain many gadgets
↓
Manipulate registers incrementally
SROP:
Control execution
↓
Prepare controlled signal frame
↓
Invoke signal return
↓
Kernel restores execution context from frame
This does not mean SROP replaces ROP or is strictly superior. They depend on different available primitives. SROP requires the ability to construct a signal frame and cause sigreturn to run, and it is intimately tied to specific kernel mechanisms, architectures, and ABIs. ROP is more general but can require more available gadgets.
Both are code-reuse techniques, in the broad sense that neither injects new executable code. But they exploit different properties of different mechanisms.
Why Context Restoration Is Such a Powerful Primitive
Controlling an instruction pointer alone is often insufficient for a useful exploit. Interesting operations tend to require specific register values: arguments need to be in the right places, the stack pointer needs to point somewhere useful, flags may need to be in a specific state.
With ordinary ROP, setting many register values requires many gadgets. Depending on the binary, finding clean gadgets for every necessary register can be difficult or impossible.
Context restoration changes the problem. A single invocation of the signal-return mechanism can potentially establish an instruction pointer, stack pointer, and a set of general-purpose registers simultaneously, because the signal frame holds all of them.
The analogy that makes this intuitive: imagine needing to configure ten physical switches to a specific configuration. One approach is to reach for each switch individually, in sequence. Another approach is to restore a saved configuration snapshot. The second approach is not always available, but when it is, it sets many values through a single operation rather than through ten sequential ones.
This is why SROP can be valuable in constrained environments where gadget availability is limited.
The Role of Architecture and ABI
SROP is not architecture-independent. Its availability and exact behavior depend heavily on:
- the CPU architecture
- the Linux kernel's ABI for that architecture
- the specific signal-frame structure
- calling conventions
- how
sigreturnorrt_sigreturnis invoked - kernel implementation details
Discussions of SROP often focus on x86-64 because it is well-documented and widely studied. On x86-64,
rt_sigreturnis a system call with a specific number, the signal frame has a specific layout, andsigreturnis distinct fromrt_sigreturn. These details matter to an attacker constructing an actual exploit and to a defender reasoning about whether a specific system is exposed.
But treating x86-64 behavior as universal would be wrong. ARM, RISC-V, MIPS, and other architectures have different signal-frame structures, different system-call interfaces, and different ABI contracts. SROP exploits a specific OS mechanism, and that mechanism's exact form is always architecture- and ABI-specific.
The attacker is interacting with a very specific contract between user space and the kernel. That contract is powerful enough to restore interrupted execution correctly, because it has to be. SROP works because it abuses exactly that power.
SROP Is Not the Initial Vulnerability
SROP is a control-flow technique, not an initial entry point. An attacker using SROP typically already has some primitive: control over execution, influence over the stack, the ability to place attacker-controlled data in useful locations.
A typical conceptual chain might look like:
Memory corruption vulnerability
↓
Initial control-flow influence
↓
Ability to position a signal frame
↓
Mechanism to invoke signal return
↓
SROP
The technique does not eliminate the need for an initial exploit primitive. It changes what can be accomplished with one by providing a powerful context-manipulation mechanism. The underlying conditions required, access to sigreturn, a predictable signal-frame layout, sufficient control over stack contents, depend on the binary, the platform, and what mitigations are in place.
How Mitigations Interact With SROP
Modern exploit mitigations address different parts of the attack chain, and none of them simply "stops SROP."
ASLR makes memory addresses unpredictable, which complicates placing a signal frame at a known location or knowing where to direct execution after context restoration. Information leaks can weaken this.
NX/DEP prevents executing writable memory as code. SROP does not require injecting executable code, so NX alone does not prevent it.
Stack canaries detect certain corruption of the stack before a function returns. Their effectiveness against SROP depends on whether the relevant corruption pattern is detected.
CFI (Control-Flow Integrity) can constrain indirect control-flow transfers, depending on implementation granularity. Its interaction with sigreturn depends on how the specific implementation handles system calls and the signal-handling path.
Shadow stacks protect return addresses. How they interact with sigreturn's context restoration depends on architecture and implementation specifics.
Seccomp can restrict the system calls a process can make. Restricting rt_sigreturn conceptually could limit SROP availability, but this requires careful thought because signal handling is a legitimate mechanism that many programs rely on.
Memory-safe languages eliminate many of the underlying corruption primitives that SROP depends on as an entry point. This is probably the most durable defense, but it operates at the language level, not the technique level.
No single mitigation makes SROP impossible across all environments. They collectively raise the bar at different points in the attack chain.
Correcting Common Misconceptions
A few errors appear often enough to address directly.
SROP is just ROP. No. They exploit different primitives. ROP chains existing instruction sequences. SROP abuses a specific OS context-restoration mechanism. They have overlapping goals but different mechanics.
sigreturn is an ordinary function call. No. It is part of the operating system's signal-handling machinery, invoked through a system call interface, and its exact behavior is architecture- and ABI-dependent.
SROP works identically on every architecture. No. The signal-frame structure, the sigreturn interface, and the ABI contract differ meaningfully between architectures.
NX/DEP prevents SROP. SROP does not require injecting executable code. NX addresses a different problem.
ASLR alone prevents SROP. ASLR makes addresses harder to predict. It does not prevent the technique; it complicates the attacker's knowledge of where things are. Information leaks can undermine it.
The Security Lesson
The surprising thing about SROP is not that an attacker discovered a dangerous system call. sigreturn is not dangerous by itself. It exists because Linux needs it.
Signal delivery requires temporarily disrupting a process's execution context. Signal return requires restoring that context precisely. The mechanism must be powerful enough to restore an entire CPU state, because that is the job.
SROP works because an attacker can interact with that mechanism in a way it was never intended to be used, abusing a contract that was designed for a completely different purpose.
This is a pattern that appears throughout systems security. A vulnerability often does not emerge from a mechanism that is broken in isolation. It emerges from the composition of legitimate mechanisms under assumptions that do not account for adversarial input.
Linux signals were designed around the assumption that the process itself is the entity delivering and returning from signals. SROP violates that assumption without violating the mechanism's formal interface.
Security fails not when mechanisms are misdesigned, but when the assumptions they rely on stop holding. The signal-return mechanism was built to trust the execution context on the stack. SROP makes that context something the attacker controls.
Top comments (0)