Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Stack Clash mitigation in GCC: Why -fstack-check is not the answer

April 30, 2019
Jeff Law
Related topics:
Security

Share:

    In our previous article about Stack Clash, we covered the basics of the Stack Clash vulnerability. To summarize, an attacker first uses various means to bring the heap and stack close together. A large stack allocation is then used to "jump the stack guard." Subsequent stores into the stack may modify objects in the heap or vice versa. This, in turn, can be used by attackers to gain control over applications.

    GCC has a capability (-fstack-check), which looked promising for mitigating Stack Clash attacks. This article will cover how -fstack-check works and why it is insufficient for mitigating Stack Clash attacks.

    Background

    GCC has a flag, -fstack-check, that is used to probe stack allocations. Carefully probing stack allocations can prevent the stack and heap from colliding and thus protect against Stack Clash attacks. So, can we use -fstack-check to prevent the stack and heap from colliding? We must understand the design/implementation decisions for -fstack-check before determining whether it's appropriate for Stack Clash mitigation.

    Ada programs enable -fstack-check to detect infinite recursion and stack overflows between different threads. Detection of either condition must result in the program reporting an error (typically via a userspace signal handler).

    Requiring the program to run a signal handler on error implies that enough stack is always available for the signal handler to execute. Thus, -fstack-check must probe beyond the current function's actual stack requirements to ensure stack space is available for the signal handler.

    Also, the entire program is assumed to be compiled with -fstack-check (a reasonable assumption if you're writing Ada code).

    The combination of those two properties is critical. Because each function probes 1-3 pages beyond its current need, any functions that are subsequently called can skip the first 1-3 pages when they probe. For example, consider this code:

    extern void bar (char *);
    
    void
    foo(void)
    {
        char z[8192];
        bar (z);
    }

    Compiled with -O2 -fstack-check results in:

    subq $12328, %rsp
     orq $0, 4104(%rsp)
     orq $0, 8(%rsp)
     orq $0, (%rsp)
     addq $4128, %rsp

    The first instruction allocates 12328 bytes of stack space (again, more than it needs so that there is always sufficient stack to run a userspace signal handler). At that point, we've already lost because that allocation could jump the stack guard and subsequent stores could be writing into the heap. The probes do not touch every allocated page. Finally, you'll note that the orq instructions (the probes) write addresses beyond the currently allocated stack. This causes significant problems for critical tools such as Valgrind.

    Using -fstack-check is insufficient for mixed environments

    Outside the Ada world, we must assume a mixed environment. The most common scenario would be to have key libraries (e.g., glibc) provided by an OS vendor interacting with userspace code provided by an ISV or customer.

    In this case, the OS vendor may have compiled the system libraries with stack checking, but the OS vendor has no control over whether or not ISVs or customers compile their code with stack checking. Let's consider what can happen in that scenario.

    To begin, let's assume the customer code does not have any large stack allocations (perhaps that's why they compiled without -fstack-check). However, the customer code has a memory leak. Assume the customer code calls into one of the glibc routines that have large stacks, and that glibc was compiled with -fstack-check.

    This seems like a safe combination, but it is not.

    Next, exploit a memory leak to bring the stack and heap close (perhaps within a page) to each other. Then call a glibc routine with a large stack. If the glibc routine were compiled with -fstack-check, then it would skip probing the first 1-3 pages (due to the design decisions/assumptions of -fstack-check). The stack pointer would now point into the heap, and stores into the stack would actually modify the heap. The stack and heap have clashed, and now there is a reasonable chance an attacker could build an exploit to gain complete control of the program.

    More issues with -fstack-check

    On some targets, the current -fstack-check implementation allocates stack space all at once, then probes at page intervals within the just allocated stack. So, what happens if the program has a signal handler installed and receives an asynchronous signal between the allocation of the stack space and probing of the pages?

    In that case, the stack pointer could be pointing beyond the guard into the heap. The signal arrives and the kernel transfers control to the registered signal handler. That signal handler is then running while its stack is pointing into the heap. Thus, the attacker has clashed the stack and heap, and there's a reasonable chance they can gain control over the program.

    To exploit this scenario, the signal delivery must occur at the right point (after stack allocation, but before probing). This further illustrates the attention to detail that is needed to protect systems from Stack Clash style attacks.

    So what should we do? Stay tuned for more details in future articles.

    Last updated: April 26, 2019

    Recent Posts

    • How to build a Model-as-a-Service platform

    • How Quarkus works with OpenTelemetry on OpenShift

    • Our top 10 articles of 2025 (so far)

    • The benefits of auto-merging GitHub and GitLab repositories

    • Supercharging AI isolation: microVMs with RamaLama & libkrun

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue