GCC

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Latest advisories Loading the feed Overview GCC builds the operating system. Every mainstream Linux distribution and effectively its whole package set is compiled with it, it is the system compiler on Debian, Ubuntu, RHEL and SUSE, and it is the toolchain for the kernel and for most embedded targets. It also ships runtime libraries into the binaries it produces, so libgcc and libstdc++ end up inside programs long after the build ends. That is where the security surface actually sits: GCC's own policy says a compiler bug counts only when it turns conforming, trusted source into vulnerable code. There is no bounty and private reports route to distribution security teams, so sorona.xyz pays you directly on qualified, reproduced findings. In scope GCC's SECURITY.txt draws the line in one place: a defect in the compiler itself is a security issue only when it generates vulnerable application code from conforming source the developer trusted. The runtime libraries GCC ships into finished binaries are evaluated separately, on their own security impact The shipped runtime libraries in full: libgcc, libstdc++, libgomp, libssp, libquadmath, libbacktrace and libatomic. All of these land inside production binaries and carry ordinary library risk libstdc++ in particular, since it is linked into a very large share of C++ software and runs on whatever data those programs receive libiberty and the other support code linked into GCC and into consumers well beyond the GCC tree Code generation across every back end and every target, where the emitted binary dereferences an invalid pointer, reads or writes the wrong address, or crashes because the codegen was wrong The optimisation passes, where a transformation applied to conforming source produces a binary with a memory-safety defect the source did not have Performance regressions in generated code severe enough to constitute denial of service, an accepted class named in the policy The C, C++, Fortran, Ada, Go, D and Modula-2 front ends, to the extent a defect propagates into generated code rather than stopping at a compile-time failure Out of scope Compiling untrusted source code. The policy states plainly that this can result in arbitrary code execution and that it should be done inside a sandbox Anything reached through a GCC plugin or through library preloading, ruled out by name Hardening features failing to catch every case. -fstack-protector , -fstack-clash-protection and _FORTIFY_SOURCE are best-effort by the policy's own statement, and a gap in one is not itself a vulnerability Failure to preserve properties the source language cannot express, such as wiping a secret from memory or holding constant-time behaviour through optimisation Compile-time crashes and internal compiler errors on malformed input, which are ordinary bugs Reports filed on GCC Bugzilla for an unfixed issue, since the project states that tracker is fully public Most-valued findings Memory-safety defects in the shipped runtime libraries, above all libstdc++ and libgcc. This is where GCC's real security activity has sat, and it is code running inside every program built against it Codegen that introduces an invalid dereference or a wrong-address read or write into a binary built from conforming source. The policy names this class explicitly and it is the only compiler-proper class it accepts Optimisation that removes or weakens a check the source actually wrote, turning safe code into exploitable code libiberty defects, since that support code is linked far beyond GCC itself and gets fed data its callers did not write Generated-code performance collapse severe enough to be a denial of service. The policy accepts this class and almost nobody reports it Anything in libgomp or the other runtime libraries reachable from data a finished program receives at runtime, since that is the point at which a library bug becomes an application bug Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. For a not-yet-public issue, contact one of the three distribution security teams the policy names: Red Hat ( [email protected] ), SUSE ( [email protected] ) or AdaCore ( [email protected] ). Those teams handle severity rating and CVE assignment GCC Bugzilla is fully public by the project's own statement, so it is the wrong place for an unfixed security issue Frame a compiler-proper finding the way the policy does: conforming source the developer trusted, compiled into a binary carrying a defect the source did not contain Runtime library findings need none of that framing. libgcc and libstdc++ are ordinary libraries and are evaluated on ordinary security impact Give the exact GCC version, the target triple and the full command line including optimisation flags. A codegen claim is not reproducible without them There is no reward. The project pays nothing and no distribution security team pays a reporter either Disclosure GCC runs no security team of its own. Private reports go to downstream distribution security teams, who rate severity, assign a CVE where one is warranted and coordinate the fix back into the tree. No timeline is published, and the practical clock is set by when distributions ship rebuilt packages rather than by a day count. Hold the detail until a fix is out. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability