What Is Procedure Linkage Table? Definition & Examples

The Procedure Linkage Table is a set of trampoline entries used by dynamically linked programs to reach external functions. Each entry redirects execution through the Global Offset Table, allowing the runtime linker to resolve a function the first time it is called.

How the Procedure Linkage Table Works

The Procedure Linkage Table, or PLT, is the call indirection layer used by dynamically linked executables to reach functions that live outside the main binary. Each PLT entry acts as a small jump target that hands control to the runtime resolver when a symbol has not yet been bound.

At a high level, the PLT exists so a program can call shared-library code without resolving every external reference up front. That design reduces startup cost and lets the loader defer symbol binding until the first use, which is why PLT entries are often described as trampolines rather than ordinary functions.

PLT, GOT, and Lazy Binding

The PLT does not work alone. It typically cooperates with the Global Offset Table, or GOT, which stores the resolved address once the linker has found the correct function. On the first call, execution passes through the PLT to the dynamic linker, which updates the relevant GOT slot and then transfers control to the target routine.

After resolution, later calls usually skip the resolver path and jump through the already populated address. This is the key efficiency trade-off of lazy binding: the first invocation pays the lookup cost, while subsequent calls are fast. It also means the PLT is part of the runtime control-flow path, not just a passive relocation detail.

Why the PLT Exists in Real Systems

In modern ELF-based systems, the PLT is one of the mechanisms that makes shared libraries practical. It allows a single binary to rely on code that may be loaded from different library versions or locations at runtime, while preserving a stable call interface inside the executable.

For software engineers and reverse engineers, the PLT is often a useful anchor point when reading disassembly or tracing imports. Calls into external libraries commonly appear as PLT stubs, which makes the structure important for understanding how an executable reaches libc, crypto libraries, or other shared dependencies.

Security Implications of PLT Indirection

The PLT is not a security control by itself, but it does shape how code execution and symbol resolution occur at runtime. Because it participates in indirection and relocation, it becomes relevant to analysis of control-flow, binary hardening, and exploitation paths that depend on predictable call targets or writable relocation data.

When attackers study dynamically linked programs, PLT and GOT behavior can matter because they reveal where external calls are routed and when resolution happens. Defenders often examine these structures during binary inspection, hardening review, and incident analysis to understand what a program may call and how those calls are bound.

Risk and Threat Considerations

PLT-based indirection can expand exposure when assumptions about loader behavior, relocation integrity, or control-flow predictability are wrong. The main risk is not the table itself, but the fact that it participates in a trusted runtime path that attackers may try to observe, tamper with, or abuse if adjacent memory protections fail.

Failure mechanism: If relocation data, code pointers, or loader-related memory regions are compromised, an attacker may redirect execution through a path that still looks legitimate to the program, making the abuse harder to notice during normal execution.

Impact: The result can be unauthorized code execution, function hijacking, or deeper compromise of the process, especially where the binary relies on predictable indirect calls and the surrounding platform lacks strong memory-protection guarantees.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1574 — Hijack Execution Flow	PLT indirection can be abused when execution flow redirection is the concern.
Recommendation — Map suspicious PLT or GOT redirection to hijack-execution-flow hunting and validate indirect call integrity.
NIST SP 800-53 Rev 5	SC-3 — Security Function Isolation	PLT/GOT integrity depends on isolating executable control paths from tampering.
	SI-16 — Memory Protection	PLT-related abuse often depends on writable or improperly protected memory regions.
Recommendation — Enforce security-function isolation to reduce the chance that runtime linkage paths are altered. Apply memory-protection controls to reduce tampering with relocation and jump targets.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Dynamic-linker behavior and binary hardening are part of secure software configuration.
Recommendation — Harden runtime linking and library-loading settings to minimize avoidable call-path exposure.
ISO/IEC 27001:2022	A.8.9 — Configuration management	PLT behavior is governed by software and runtime configuration that must be controlled.
Recommendation — Manage binary and loader configuration changes so runtime linkage behavior stays intentional and reviewed.

Practitioner Guidance

What to watch for: Treat PLT entries as a normal part of dynamic linking, not as a special feature to optimize away. For security review, the important question is whether the executable and its loader environment preserve the integrity of indirect calls, relocations, and library resolution.

Practitioner takeaway: When you inspect a binary, read the PLT together with the GOT and relocation records, because the security story is in the call path they create, not in the PLT alone.

Procedure Linkage Table