GDB

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 CVE history 5 Last 12 months Privilege boundary 35 % Code execution 30 % Memory safety 25 % Info disclosure 10 % Latest advisories Loading the feed Overview GDB is the default debugger everywhere Linux is developed, and gdbserver is the remote half sitting under most embedded and cross-target work and behind a great many IDE debug backends. The interesting property is that a debugger opens files it did not write: core dumps, binaries and separate debug info, some of it fetched over the network by a debuginfod client that modern GDB enables by default. GDB's policy accepts exactly two things, a bug that crosses a privilege boundary and a bug that runs the debuggee without the user asking. The project pays nothing and private reports go to distribution security teams, so sorona.xyz pays you directly on qualified, reproduced findings. In scope GDB's SECURITY.txt states its accepted classes outright: any bug in GDB or gdbserver that results in an unexpected crossing of a privilege boundary, and any bug that results in execution of the program being debugged without a user command triggering it. Both cover the whole tree, gdb and gdbserver alike Everything GDB parses that it did not produce: ELF binaries, separate debug info files, core dumps, and the DWARF readers underneath all of them gdbserver end to end, including the remote protocol handling on the GDB side of the connection Any path that can start execution of the debuggee without a user command, including anything auto-loaded when a file is opened The extension script machinery, to the extent GDB acts on data carried by the file under inspection rather than on the user's own configuration gcore and gdb-add-index, the auxiliary tools shipped alongside GDB's own handling of a misbehaving remote stub. The policy puts third-party stubs out of scope but keeps GDB's reaction to one in scope The debuginfod client path, enabled by default in modern GDB, where debug data arrives over the network from a server the developer never audited Out of scope The contents of user and system configuration files and plugins, which the policy treats as trusted input The GDB to gdbserver connection itself. The policy calls it insecure by design and places responsibility for securing it on the user Third-party remote stubs, though a GDB defect triggered by a misbehaving stub remains in scope Known undefined behaviour from a malformed program under inspection. The policy accepts these reports but marks them explicitly low priority absent a demonstrated boundary breach Defects in the program being debugged rather than in GDB Reports filed on the public Sourceware Bugzilla for an issue that is not yet public Most-valued findings Execution of the debuggee before the user issued any command that should have started it. The policy names this class on its own and it is the sharpest thing to hunt here Any unexpected crossing of a privilege boundary in GDB or gdbserver, the other named class. gdbserver is the component that routinely runs with more privilege than whoever is driving it Memory corruption in the ELF or DWARF readers where you can show a boundary breach on top of the crash. Upstream absorbs plain crashes, so the demonstration is what makes the report Anything reachable through the debuginfod client, since it pulls debug data over the network by default and GDB then parses it GDB mishandling a response from a stub or a remote target in a way that compromises the machine running GDB, which is the developer workstation Auto-loading behaviour where opening a file is enough to change what runs, rather than only what is displayed 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, email one of the two distribution security teams the policy names: Red Hat ( [email protected] ) or SUSE ( [email protected] ) Sourceware Bugzilla is the public path and the policy says so, so use it only for issues that are already public Map the finding onto one of the two accepted classes: a privilege boundary crossed unexpectedly, or the debuggee executing without a user command that triggered it A crash on a malformed binary is reportable but explicitly low priority by policy. Demonstrate the trust boundary breach or expect it triaged as an ordinary bug Do not report the GDB to gdbserver link as insecure. The policy already states it is insecure by design and puts securing it on the user There is no reward. The project pays nothing and neither distribution security team pays a reporter Disclosure GDB runs no security team of its own. Private reports go to Red Hat and SUSE, who rate severity, assign a CVE where warranted and coordinate the fix upstream on Sourceware. No timeline is published, and the practical clock runs to a patched release plus distribution rebuilds. Hold the detail until that lands. 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