head 1.1; branch 1.1.1; access; symbols netbsd-11-0-RC6:1.1.1.1 netbsd-11-0-RC5:1.1.1.1 netbsd-11-0-RC4:1.1.1.1 netbsd-11-0-RC3:1.1.1.1 gdb-17-1:1.1.1.2 netbsd-11-0-RC2:1.1.1.1 netbsd-11-0-RC1:1.1.1.1 gdb-16-3:1.1.1.2 perseant-exfatfs:1.1.1.1.0.4 perseant-exfatfs-base-20250801:1.1.1.1 netbsd-11:1.1.1.1.0.2 netbsd-11-base:1.1.1.1 gdb-15-1:1.1.1.1 FSF:1.1.1; locks; strict; comment @# @; 1.1 date 2024.08.12.21.38.08; author christos; state Exp; branches 1.1.1.1; next ; commitid dWD83H91pFit0AlF; 1.1.1.1 date 2024.08.12.21.38.08; author christos; state Exp; branches 1.1.1.1.4.1; next 1.1.1.2; commitid dWD83H91pFit0AlF; 1.1.1.2 date 2025.08.27.17.29.22; author christos; state Exp; branches; next ; commitid vgUAu9EQfEWNko8G; 1.1.1.1.4.1 date 2024.08.12.21.38.08; author perseant; state dead; branches; next 1.1.1.1.4.2; commitid 23j6GFaDws3O875G; 1.1.1.1.4.2 date 2025.08.02.05.26.40; author perseant; state Exp; branches; next ; commitid 23j6GFaDws3O875G; desc @@ 1.1 log @Initial revision @ text @GNU Debugger Security Policy ============================ Introduction ------------ The GNU Debugger (GDB) is a tool for diagnosing issues "inside" another program. This can be done by controlling the execution of the program being debugged and allowing the user to inspect and modify the state of the running program. Or GDB can be used to analyse the program or a core file generated from the program without needing to execute the program. The program being debugged may be local i.e. on the system on which GDB runs or remote, on a different system. Policy Objectives ----------------- The objective of this policy is define what the GDB project considers a security bug and what is a non-security bug, and how bugs can be reported. Additionally this policy discusses areas of GDB in which there are known bugs, how these might lead to security issues, and how this risk can be mitigated. Scope Of This Policy -------------------- This policy covers all currently supported versions of GDB as released from the official GDB website and covers gdb, gdbserver, as well as gcore and gdb-add-index, which are packaged with each GDB release. The official GDB website can be found here: https://sourceware.org/gdb/ Remote debugging uses GDB to connect to a remote target. GDB sends commands to the remote target which then controls the process being debugged. The GDB project provides one remote target, gdbserver, which is included with official GDB releases. Bugs within gdbserver are in scope for this policy. Other projects also implement remote targets to which GDB can connect. Any bugs in these remote targets are out of scope for this policy and should be reported to the relevant project. However, any bugs in GDB caused by a misbehaving remote target, even when that target is not gdbserver, are in scope for this policy. What Is A Security Bug? ----------------------- Any bugs in GDB or gdbserver that result in an unexpected crossing of a privilege boundary are considered security bugs. Some examples of crossing a privilege boundary include: being able to execute code as an arbitrarily different user, or accessing resources (e.g. files, sockets, etc) for which the original user would not normally have access. Any bugs in GDB that result in execution of the program being debugged without the user issuing a GDB command triggering execution (either from the GDB command line, a GDB configuration file, or from the GDB prompt) are considered security bugs. GDB will check for and load multiple configuration files. When initially started GDB can load user- and system-specific configuration files, this is done unconditionally as it is assumed these files are under control of the user and are always safe to load. GDB can also load per-project and per-program configuration files, this is done when a program to debug is loaded into GDB. These configuration files will only be loaded if the user has given GDB permission to load these files. Any bug in GDB which allows per-project or per-program configuration files to be loaded without permission having been granted by the user is considered a security bug. When gdbserver is started, if it is passed a program on its command line then that program will be started, but paused before executing its first instruction. Any bug in gdbserver which results in further execution of the program being debugged without GDB first connecting to the target and sending a command that is intended to trigger execution is a security bug in gdbserver. Any bug in GDB or gdbserver that can trigger arbitrary code execution without the program being debugged having been executed by a user command, is considered a security bug, e.g. if loading a program into GDB could trigger arbitrary code execution, then this is a security issue. The additional tools gcore and gdb-add-index are scripts that wrap around GDB. Any issue in these tools that meet the above definitions of a security bug, are considered a security bug. What Is Not A Security Bug -------------------------- In the context of local debugging, when GDB is used to execute a program, the program runs with the same privileges as GDB itself. Any issues that arise from running an untrusted program outside of a secure environment are not security bugs in GDB. Any issues that arise from running an untrusted program through GDB inside a secure environment are only security bugs if GDB is required in order to trigger the issue. It is possible for a program to detect when it is run under GDB and to change its behavior so that unwanted behavior may only appear when a program is run under GDB. Any issues that arise due to an untrusted program detecting GDB and changing its behaviour are not security issues in GDB unless the issue also meet some other definition of a security bug. In the context of remote debugging, the program being debugged is run with the same privileges as gdbserver. As with GDB in the local debugging case, any issues that arise from running an untrusted program outside of a secure environment are not security bugs in gdbserver. The connection between GDB and a remote target is not protected by either authentication or encryption. Connecting to a remote target allows for arbitrary code execution on the remote system with the same privileges as the remote user, and any resource that the remote user can access can be read by GDB, and downloaded to the local machine on which GDB is running. As such, users need to take independent measures to secure the connection between GDB and the remote target. Any issues that arise due to a failure to protect the connection between GDB and a remote target are not security bugs in either GDB or gdbserver. Security Realities Of The GDB Project ------------------------------------- Within this section, references to GDB should be read as meaning GDB, gdbserver, gcore, or gdb-add-index, unless specifically stated otherwise. The most common use case for GDB is a developer trying to resolve issues within a program that they have either written themselves, or within a program that they trust not to be malicious. In this situation we would say GDB is being used to debug trusted code. There is no greater security risk from running the program to debug through GDB than there is running the program directly. Additional process isolation for the GDB process is only needed if additional isolation would have been applied anyway when running the program to debug. In some cases a developer may be given a program from an untrusted source and be asked to debug an issue. In this situation we would say GDB is being used to debug untrusted code. In this case the user should take all the precautions when running GDB that they would normally take when running an untrusted program outside of GDB, e.g. running within a secure, sandboxed environment. When using GDB to examine, but not execute, an untrusted program (with gdbserver, the program will be started, but paused at the first instruction and not run further), there should be no security risks, however the GDB maintainers don't currently believe that GDB or gdbserver is reliable enough to ensure that there are no security risks. There are known bugs in GDB related to loading malformed executables and parsing the debug information, a consequence of these bugs is that a malicious program could trigger undefined behaviour in GDB, which could be used to trigger arbitrary code execution. Given these risks, the advice of the GDB project is that, when using GDB with an untrusted binary, always do so in a secure, sandboxed environment. As there are already known bugs in GDB relating to undefined behaviour triggered from malformed programs, further bugs in this area should still be reported, but are unlikely to be given high priority. Bugs in GDB that are triggered by well-formed programs should also be reported, and are likely to be treated as higher priority as these are more likely to impact normal use of GDB. When using GDB and gdbserver to perform remote debug, the connection between the two components is by design insecure. It is up to the user to protect this connection, for example, by only starting gdbserver within a secure network. Reporting Non-Security Bugs --------------------------- NOTE: All bugs reported in the GDB Bugzilla are public. Non-security bugs, as well as any security bugs that pose limited risk to users should be reported in GDB's bugzilla system. Bugs reported in this way will be public. The bugzilla system can be found here: https://sourceware.org/bugzilla/ Reporting Security Bugs ----------------------- In order to report a private security bug that is not immediately made public, please contact one of the downstream distributions with security teams. The following teams have volunteered to handle such bugs: Red Hat: secalert@@redhat.com SUSE: security@@suse.de 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 keeping details of the bug private. @ 1.1.1.1 log @Import gdb-15.1, previous was 13.2 ChangeLog: 2024-03-20 Simon Marchi * .pre-commit-config.yaml: Bump black hook to 24.3.0 2024-03-20 Simon Marchi * .pre-commit-config.yaml: New. 2024-03-14 Simon Marchi * Makefile.def: Add configure-gdbserver and all-gdbserver dependencies on all-libiconv. * Makefile.in: Re-generate. 2024-01-15 Nick Clifton * 2.42 branch point. 2023-11-15 Arsen Arsenović * intl: Remove directory. Replaced with out-of-tree GNU gettext. * .gitignore: Add '/gettext*'. * configure.ac (host_libs): Replace intl with gettext. (hbaseargs, bbaseargs, baseargs): Split baseargs into {h,b}baseargs. (skip_barg): New flag. Skips appending current flag to bbaseargs. : Exempt --with-libintl-{type,prefix} from target and build machine argument passing. * configure: Regenerate. * Makefile.def (host_modules): Replace intl module with gettext module. (configure-ld): Depend on configure-gettext. * Makefile.in: Regenerate. * src-release.sh: Remove references to the intl/ directory. 2023-07-03 Nick Clifton 2.41 Branch Point. 2023-06-26 Nick Clifton * Import these updates to the config scripts commit 4ad4bb7c30aca1e705448ba8d51a210bbd47bb52 Author: Paul Eggert Date: Fri Jun 23 09:55:10 2023 -0700 Quote 'like this', not `like this'. commit 63acb96f92473ceb5e21d873d7c0aee266b3d6d3 Author: Paul Eggert Date: Sat Jan 21 00:15:01 2023 -0600 Fix config.sub spelling typo for "athlon" commit 4ce12a5c9125cedc0d0ba584444a6865396923ec Author: Dmitry V. Levin Date: Sun Jan 1 08:00:00 2023 +0000 Update copyright years commit c397e2c040bce50bcdccb131f90115ba7e8bfc19 Author: Arsen Arsenovi Date: Sat Sep 17 23:34:48 2022 +0200 config.sub: add linux-mlibc targets commit 9f9f9b0b13197269848c76e3e057a3ed0680b4bf Author: Arsen Arsenovi Date: Sat Sep 17 23:34:47 2022 +0200 config.guess: support running on Managarm systems commit 87e6687749da7bb2ab158a79fa83721c19ed9246 Author: Arsen Arsenovi Date: Sat Sep 17 23:34:46 2022 +0200 config.sub: add managarm-{mlibc,kernel} targets commit 20403c5701973a4cbd7e0b4bbeb627fcd424a0f1 Author: Xiaotian Wu Date: Mon Aug 1 16:05:29 2022 +0800 Remove loongarchx32 commit 02ba26b218d3d3db6c56e014655faf463cefa983 Author: Alexander von Gluck IV Date: Wed May 25 15:43:13 2022 -0500 config.guess: Update Haiku guesses commit f56a7140386d08a531bcfd444d632b28c61a6329 Author: Bruno Haible Date: Sun May 8 19:08:08 2022 +0200 config.guess (x86_64:Linux:*:*): Detect 32-bit ABI. 2023-04-20 Nick Clifton * SECURITY.txt: New file. * src-release.sh (DEVO_SUPPORT): Add SECURITY.txt. 2022-12-31 Nick Clifton * 2.40 binutils branch created. @ text @@ 1.1.1.2 log @Import gdb 16.3; previous was 15.1 April 20th, 2025: GDB 16.3 Released! The latest version of GDB, version 16.3, is available for download. This is a corrective release over GDB 16.2, fixing the following issues: PR symtab/32309 ([gdb/symtab, fission] gdb/dwarf2/read.h:289: internal-error: version: Assertion `m_dwarf_version != 0' failed) PR corefiles/32441 (gdb segfaults when generating a core file if target_fileio_read_alloc fails) PR tui/32623 (TUI console window doesn't update while inferior is running) PR corefiles/32634 ([gdb/corefiles] segfault in gdb.arch/i386-biarch-core.exp) PR backtrace/32757 ("Assertion `stashed' failed" when inline frame #0 is duplicated) PR tdep/32770 ([gdb/tdep, i386] FAIL: gdb.reverse/recvmsg-reverse.exp: continue to breakpoint: marker2) PR gdb/32775 ([AArch64] gdbserver crashes on SVE/SME-enabled systems) PR record/32784 ([gdb/record, aarch64] Stack smashing detected in aarch64_record_asimd_load_store) PR tui/32797 (Escape sequences to only reset foreground or background color to default fail) PR gdb/32828 (gstack regression: missing file names and line numbers) See the NEWS file for a more complete and detailed list of what this release includes. February 1st, 2025: GDB 16.2 Released! The latest version of GDB, version 16.2, is available for download. This is a corrective release over GDB 16.1, fixing the following issues: PR build/32578 (cannot build GDB 16.1 out of tree when calling the configure script with a relative path) PR tui/32592 ([gdb/tui] internal error in tui-winsource.c:340:refresh_window) PR remote/32593 (Incompatibilities between GDB's and LLDB's 'x' packet implementation) PR build/32610 (Missing #include file in darwin_nat.c) See the NEWS file for a more complete and detailed list of what this release includes. January 18th, 2025: GDB 16.1 Released! The latest version of GDB, version 16.1, is available for download. This version of GDB includes the following changes and enhancements: record/replay support now available on loongarch*-linux* GDB now supports watchpoints for tagged data pointers. MTE (Memory Tagging Extension) debugging is now supported on AArch64 baremetal. New bash script gstack uses GDB to print stack traces of running processes. Enhanced breakpoint support For breakpoints that are created in the 'pending' state, any 'thread' or 'task' keywords are parsed at the time the breakpoint is created, rather than at the time the breakpoint becomes non-pending. Thread-specific breakpoints are only inserted into the program space in which the thread of interest is running. Enhanced Intel Processor Trace support Support for printing of asynchronous events Support for printing of ptwrite payloads Changed commands The "remove-symbol-file -a ADDRESS" command now accepts a full expression as the ADDRESS. The "show configuration" command now prints the version of GNU readline that GDB is using. The "maintenance print remote-registers" now provides an "Expedited" column indicating which registers were included in the last stop reply packet received by GDB. Various command taking filenames as argument now require file names to be quoted if the argument contains white spaces or quote characters. Python API changes New module gdb.missing_objfile that facilitates dealing with missing objfiles when opening a core-file. GDB commands to query, enable and disable handlers created using this API have also been added. New event gdb.tui_enabled. Added the gdb.Symbol.is_artificial attribute. New gdb.record.clear function to clear the trace data of the current recording. The 'signed' argument to gdb.Architecture.integer_type() will no longer accept non-bool types. The gdb.MICommand.installed property can only be set to True or False. The 'qualified' argument to gdb.Breakpoint constructor will no longer accept non-bool types. Debugger Adapter Protocol changes The "scopes" request will now return a scope holding global variables from the stack frame's compilation unit. The "scopes" request will return a "returnValue" scope holding the return value from the latest "stepOut" command, when appropriate. The "launch" and "attach" requests were rewritten in accordance with some clarifications to the spec. Now they can be sent at any time after the "initialized" event, but will not take effect (or send a response) until after the "configurationDone" request has been sent. The "variables" request will not return artificial symbols. Remote Protocol New remote packet: vFile:stat New remote packet: x addr,length Miscellaneous The Ada 'Object_Size attribute is now supported. Styling now available for line numbers, GDB commands and header lines of lists. It is now possible to turn the warning emitted when specifying a language that does not match the current frame off. For ARM targets, the offset of the pc in the jmp_buf has been fixed to match glibc 2.20 and later. This should only matter when not using libc probes. This may cause breakage when using an incompatible libc, like uclibc or newlib, or an older glibc. Deprecated or removed Support for QNX Neutrino has been removed Support for Nios II targets has been removed Support for Intel MPX has been removed See the NEWS file for a more complete and detailed list of what this release includes. December 29th, 2024: GDB 16 branch created The GDB 16 branch (gdb-16-branch) has been created. To check out a copy of the branch use: git clone --branch gdb-16-branch https://sourceware.org/git/binutils-gdb.git September 29th, 2024: GDB 15.2 Released! The latest version of GDB, version 15.2, is available for download. This is a minor corrective release over GDB 15.1, fixing the following issues: PR gdb/31727 (-exec-next fails in mingw (infrun.c:2794: internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)' failed)) PR c++/31900 (libstdc++-prettyprinters/debug.cc print redirected fails since gdb-14-branchpoint-2123-g4e417d7bb1c) PR python/31946 (sys.exit from Python no longer exits the GDB process) PR record/31971 (Loading a saved record file asserts if we try to execute the inferior) PR gdb/32005 (frv_current_sos doesn't set solib::lm_info) PR exp/32015 (GDB crashes while printing large D array) PR gdb/32025 (Fatal error when the disassemble command is interrupted with SIGINT) PR gdb/32143 ([15 Regression] arch/amd64.c:71: internal-error: amd64_create_target_description: Assertion `!is_x32' failed) PR symtab/32158 ([gdb/symtab] enum class enumerator has incorrect parent in cooked index) PR symtab/32160 ([gdb/symtab] Parent map: die parent or scope parent?) See the NEWS file for a more complete and detailed list of what this release includes. @ text @d65 13 a77 19 GDB will check for and load multiple configuration files, sometimes referred to as extension scripts or plugins. When initially started GDB can load user-specific and/or system-specific configuration files, this is done unconditionally as it is assumed these files are under control of the user and are always safe to load. All of these files are treated as trusted input, meaning GDB makes no attempt to sanitize commands and has no sandboxing or other protections against effects of commands run by any automatically loaded file. It is up to the user to audit files against documentation provided by the relevant projects to protect against malicious commands. If executing commands provided by the GDB project generates undocumented side effects, this is a bug. For that bug to be considered a security bug, it must meet other definitions of security bugs outlined in this document. GDB can also load per-project and/or per-program configuration files when a program is loaded for debugging. Such files will only be loaded if the user has given GDB permission to load them. Any bug in GDB which allows per-project or per-program configuration files to be loaded without permission having been granted by the user is considered a security bug. a103 19 GDB is not meant to be offered as a service (that is, offered over an insecure connection to non-local users), and so denial of service attacks targeting GDB itself, or other bugs that target this use case, are not considered a security bug. By the same token, simply triggering an internal error in GDB is not considered a security bug, since GDB has detected an issue and handled it in a non-exploitable manner. If it can be demonstrated that some bug other than the internal error happens, this other bug should be evaluated independently of the error, and may be a security bug if it fits some of the definitions in this document. GDB provides 3 different turing complete languages, Guile, Python and direct access to the shell. Making use of these languages can have unknown effects, including outside of the GDB process. Such effects will only be considered security bugs if they fit some of the definitions in this document and the effect can only be reproduced when executed in the GDB environment. d113 1 a113 1 untrusted program detecting GDB and changing its behavior are not d169 1 a169 1 that a malicious program could trigger undefined behavior in GDB, d177 1 a177 1 behavior triggered from malformed programs, further bugs in this @ 1.1.1.1.4.1 log @file SECURITY.txt was added on branch perseant-exfatfs on 2025-08-02 05:26:40 +0000 @ text @d1 218 @ 1.1.1.1.4.2 log @Sync with HEAD @ text @a0 218 GNU Debugger Security Policy ============================ Introduction ------------ The GNU Debugger (GDB) is a tool for diagnosing issues "inside" another program. This can be done by controlling the execution of the program being debugged and allowing the user to inspect and modify the state of the running program. Or GDB can be used to analyse the program or a core file generated from the program without needing to execute the program. The program being debugged may be local i.e. on the system on which GDB runs or remote, on a different system. Policy Objectives ----------------- The objective of this policy is define what the GDB project considers a security bug and what is a non-security bug, and how bugs can be reported. Additionally this policy discusses areas of GDB in which there are known bugs, how these might lead to security issues, and how this risk can be mitigated. Scope Of This Policy -------------------- This policy covers all currently supported versions of GDB as released from the official GDB website and covers gdb, gdbserver, as well as gcore and gdb-add-index, which are packaged with each GDB release. The official GDB website can be found here: https://sourceware.org/gdb/ Remote debugging uses GDB to connect to a remote target. GDB sends commands to the remote target which then controls the process being debugged. The GDB project provides one remote target, gdbserver, which is included with official GDB releases. Bugs within gdbserver are in scope for this policy. Other projects also implement remote targets to which GDB can connect. Any bugs in these remote targets are out of scope for this policy and should be reported to the relevant project. However, any bugs in GDB caused by a misbehaving remote target, even when that target is not gdbserver, are in scope for this policy. What Is A Security Bug? ----------------------- Any bugs in GDB or gdbserver that result in an unexpected crossing of a privilege boundary are considered security bugs. Some examples of crossing a privilege boundary include: being able to execute code as an arbitrarily different user, or accessing resources (e.g. files, sockets, etc) for which the original user would not normally have access. Any bugs in GDB that result in execution of the program being debugged without the user issuing a GDB command triggering execution (either from the GDB command line, a GDB configuration file, or from the GDB prompt) are considered security bugs. GDB will check for and load multiple configuration files. When initially started GDB can load user- and system-specific configuration files, this is done unconditionally as it is assumed these files are under control of the user and are always safe to load. GDB can also load per-project and per-program configuration files, this is done when a program to debug is loaded into GDB. These configuration files will only be loaded if the user has given GDB permission to load these files. Any bug in GDB which allows per-project or per-program configuration files to be loaded without permission having been granted by the user is considered a security bug. When gdbserver is started, if it is passed a program on its command line then that program will be started, but paused before executing its first instruction. Any bug in gdbserver which results in further execution of the program being debugged without GDB first connecting to the target and sending a command that is intended to trigger execution is a security bug in gdbserver. Any bug in GDB or gdbserver that can trigger arbitrary code execution without the program being debugged having been executed by a user command, is considered a security bug, e.g. if loading a program into GDB could trigger arbitrary code execution, then this is a security issue. The additional tools gcore and gdb-add-index are scripts that wrap around GDB. Any issue in these tools that meet the above definitions of a security bug, are considered a security bug. What Is Not A Security Bug -------------------------- In the context of local debugging, when GDB is used to execute a program, the program runs with the same privileges as GDB itself. Any issues that arise from running an untrusted program outside of a secure environment are not security bugs in GDB. Any issues that arise from running an untrusted program through GDB inside a secure environment are only security bugs if GDB is required in order to trigger the issue. It is possible for a program to detect when it is run under GDB and to change its behavior so that unwanted behavior may only appear when a program is run under GDB. Any issues that arise due to an untrusted program detecting GDB and changing its behaviour are not security issues in GDB unless the issue also meet some other definition of a security bug. In the context of remote debugging, the program being debugged is run with the same privileges as gdbserver. As with GDB in the local debugging case, any issues that arise from running an untrusted program outside of a secure environment are not security bugs in gdbserver. The connection between GDB and a remote target is not protected by either authentication or encryption. Connecting to a remote target allows for arbitrary code execution on the remote system with the same privileges as the remote user, and any resource that the remote user can access can be read by GDB, and downloaded to the local machine on which GDB is running. As such, users need to take independent measures to secure the connection between GDB and the remote target. Any issues that arise due to a failure to protect the connection between GDB and a remote target are not security bugs in either GDB or gdbserver. Security Realities Of The GDB Project ------------------------------------- Within this section, references to GDB should be read as meaning GDB, gdbserver, gcore, or gdb-add-index, unless specifically stated otherwise. The most common use case for GDB is a developer trying to resolve issues within a program that they have either written themselves, or within a program that they trust not to be malicious. In this situation we would say GDB is being used to debug trusted code. There is no greater security risk from running the program to debug through GDB than there is running the program directly. Additional process isolation for the GDB process is only needed if additional isolation would have been applied anyway when running the program to debug. In some cases a developer may be given a program from an untrusted source and be asked to debug an issue. In this situation we would say GDB is being used to debug untrusted code. In this case the user should take all the precautions when running GDB that they would normally take when running an untrusted program outside of GDB, e.g. running within a secure, sandboxed environment. When using GDB to examine, but not execute, an untrusted program (with gdbserver, the program will be started, but paused at the first instruction and not run further), there should be no security risks, however the GDB maintainers don't currently believe that GDB or gdbserver is reliable enough to ensure that there are no security risks. There are known bugs in GDB related to loading malformed executables and parsing the debug information, a consequence of these bugs is that a malicious program could trigger undefined behaviour in GDB, which could be used to trigger arbitrary code execution. Given these risks, the advice of the GDB project is that, when using GDB with an untrusted binary, always do so in a secure, sandboxed environment. As there are already known bugs in GDB relating to undefined behaviour triggered from malformed programs, further bugs in this area should still be reported, but are unlikely to be given high priority. Bugs in GDB that are triggered by well-formed programs should also be reported, and are likely to be treated as higher priority as these are more likely to impact normal use of GDB. When using GDB and gdbserver to perform remote debug, the connection between the two components is by design insecure. It is up to the user to protect this connection, for example, by only starting gdbserver within a secure network. Reporting Non-Security Bugs --------------------------- NOTE: All bugs reported in the GDB Bugzilla are public. Non-security bugs, as well as any security bugs that pose limited risk to users should be reported in GDB's bugzilla system. Bugs reported in this way will be public. The bugzilla system can be found here: https://sourceware.org/bugzilla/ Reporting Security Bugs ----------------------- In order to report a private security bug that is not immediately made public, please contact one of the downstream distributions with security teams. The following teams have volunteered to handle such bugs: Red Hat: secalert@@redhat.com SUSE: security@@suse.de 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 keeping details of the bug private. @