gcc/SECURITY.txt

What is a GCC security bug?
===========================

    A security bug is one that threatens the security of a system or
    network, or might compromise the security of data stored on it.
    In the context of GCC, there are multiple ways in which this might
    happen and some common scenarios are detailed below.

    If you're reporting a security issue and feel like it does not fit
    into any of the descriptions below, you're encouraged to reach out
    through the GCC bugzilla or, if needed, privately, by following the
    instructions in the last two sections of this document.

Compiler drivers, programs, libgccjit and support libraries
-----------------------------------------------------------

    The compiler driver processes source code, invokes other programs
    such as the assembler and linker and generates the output result,
    which may be assembly code or machine code.  Compiling untrusted
    sources can result in arbitrary code execution and unconstrained
    resource consumption in the compiler. As a result, compilation of
    such code should be done inside a sandboxed environment to ensure
    that it does not compromise the host environment.

    The libgccjit library can, despite the name, be used both for
    ahead-of-time compilation and for just-in-compilation.  In both
    cases, it can be used to translate input representations (such as
    source code) in the application context; in the latter case, the
    generated code is also run in the application context.

    Limitations that apply to the compiler driver apply here too in
    terms of trusting inputs and it is recommended that both the
    compilation *and* execution context of the code are appropriately
    sandboxed to contain the effects of any bugs in libgccjit, the
    application code using it, or its generated code to the sandboxed
    environment.

    Libraries such as libiberty, libcc1 and libcpp are not distributed
    for runtime support and have similar challenges to compiler drivers.
    While they are expected to be robust against arbitrary input, they
    should only be used with trusted inputs when linked into the
    compiler.

    Libraries such as zlib that are bundled with GCC to build it will be
    treated the same as the compiler drivers and programs as far as
    security coverage is concerned.  However, if you find an issue in
    these libraries independent of their use in GCC, you should reach
    out to their upstream projects to report them.

    As a result, the only case for a potential security issue in the
    compiler is when it generates vulnerable application code for
    trusted input source code that is conforming to the relevant
    programming standard or extensions documented as supported by GCC
    and the algorithm expressed in the source code does not have the
    vulnerability.  The output application code could be considered
    vulnerable if it produces an actual vulnerability in the target
    application, for example:

    - The application dereferences an invalid memory location despite
      the application sources being valid.
    - The application reads from or writes to a valid but incorrect
      memory location, resulting in an information integrity issue or an
      information leak.
    - The application ends up running in an infinite loop or with
      severe degradation in performance despite the input sources having
      no such issue, resulting in a Denial of Service.  Note that
      correct but non-performant code is not a security issue candidate,
      this only applies to incorrect code that may result in performance
      degradation severe enough to amount to a denial of service.
    - The application crashes due to the generated incorrect code,
      resulting in a Denial of Service.

Language runtime libraries
--------------------------

    GCC also builds and distributes libraries that are intended to be
    used widely to implement runtime support for various programming
    languages.  These include the following:

    * libada
    * libatomic
    * libbacktrace
    * libcc1
    * libcody
    * libcpp
    * libdecnumber
    * libffi
    * libgcc
    * libgfortran
    * libgm2
    * libgo
    * libgomp
    * libitm
    * libobjc
    * libphobos
    * libquadmath
    * libssp
    * libstdc++

    These libraries are intended to be used in arbitrary contexts and, as
    a result, bugs in these libraries may be evaluated for security
    impact.  However, some of these libraries, e.g. libgo, libphobos,
    etc.  are not maintained in the GCC project, due to which the GCC
    project may not be the correct point of contact for them.  You are
    encouraged to look at README files within those library directories
    to locate the canonical security contact point for those projects
    and include them in the report.  Once the issue is fixed in the
    upstream project, the fix will be synced into GCC in a future
    release.

    Most security vulnerabilities in these runtime libraries arise when
    an application uses functionality in a specific way.  As a result,
    not all bugs qualify as security relevant.  The following guidelines
    can help with the decision:

    - Buffer overflows and integer overflows should be treated as
      security issues if it is conceivable that the data triggering them
      can come from an untrusted source.
    - Bugs that cause memory corruption which is likely exploitable
      should be treated as security bugs.
    - Information disclosure can be security bugs, especially if
      exposure through applications can be determined.
    - Memory leaks and races are security bugs if they cause service
      breakage.
    - Stack overflow through unbounded alloca calls or variable-length
      arrays are security bugs if it is conceivable that the data
      triggering the overflow could come from an untrusted source.
    - Stack overflow through deep recursion and other crashes are
      security bugs if they cause service breakage.
    - Bugs that cripple the whole system (so that it doesn't even boot
      or does not run most applications) are not security bugs because
      they will not be exploitable in practice, due to general system
      instability.

Diagnostic libraries
--------------------

    Libraries like libvtv and the sanitizers are intended to be used in
    diagnostic cases and not intended for use in sensitive environments.
    As a result, bugs in these libraries will not be considered security
    sensitive.

GCC plugins
-----------

    It should be noted that GCC may execute arbitrary code loaded by a
    user through the GCC plugin mechanism or through system preloading
    mechanism.  Such custom code should be vetted by the user for safety,
    as bugs exposed through such code will not be considered security
    issues.

Security features implemented in GCC
------------------------------------

    GCC implements a number of security features that reduce the impact
    of security issues in applications, such as -fstack-protector,
    -fstack-clash-protection, _FORTIFY_SOURCE and so on.  A failure of
    these features to function perfectly in all situations is not a
    vulnerability in itself since it does not affect the correctness of
    programs.  Further, they're dependent on heuristics and may not
    always have full coverage for protection.

    Similarly, GCC may transform code in a way that the correctness of
    the expressed algorithm is preserved, but supplementary properties
    that are not specifically expressible in a high-level language
    are not preserved. Examples of such supplementary properties
    include absence of sensitive data in the program's address space
    after an attempt to wipe it, or data-independent timing of code.
    When the source code attempts to express such properties, failure
    to preserve them in resulting machine code is not a security issue
    in GCC.

Reporting private security bugs
===============================

    *All bugs reported in the GCC Bugzilla are public.*

    In order to report a private security bug that is not immediately
    public, please contact one of the downstream distributions with
    security teams.  The following teams have volunteered to handle
    such bugs:

      Debian:  security@debian.org
      Red Hat: secalert@redhat.com
      SUSE:    security@suse.de
      AdaCore: product-security@adacore.com

    Please report the bug to just one of these teams.  It will be shared
    with other teams as necessary.

    The team contacted will take care of details such as vulnerability
    rating and CVE assignment (http://cve.mitre.org/about/).  It is likely
    that the team will ask to file a public bug because the issue is
    sufficiently minor and does not warrant an embargo.  An embargo is not
    a requirement for being credited with the discovery of a security
    vulnerability.

Reporting public security bugs
==============================

    It is expected that critical security bugs will be rare, and that most
    security bugs can be reported in GCC, thus making
    them public immediately.  The system can be found here:

      https://gcc.gnu.org/bugzilla/