Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
Both of the issues here are in the function xcoff_link_add_symbols in the file bfd/xcofflink.c. Here is an AI analysis of how this function is used, and whether it can be called from GDB: 1. xcoff_link_add_symbols is a static function in bfd/xcofflink.c called by _bfd_xcoff_bfd_link_add_symbols. That public function is installed in the XCOFF BFD target vectors (rs6000_xcoff_vec, powerpc_xcoff_vec, and the 64-bit variants in coff64-rs6000.c) via BFD_JUMP_TABLE_LINK(_bfd_xcoff). 2. The only way to invoke it is through the BFD dispatch macro: #define bfd_link_add_symbols(abfd, info) \ BFD_SEND (abfd, _bfd_link_add_symbols, (abfd, info)) This is a linker API — it's how the linker (ld) tells BFD to add symbols from an input object/archive into the link hash table during a link operation. 3. GDB never calls bfd_link_add_symbols: A search of the entire gdb/, gdbserver/, and gdbsupport/ trees finds zero calls to bfd_link_add_symbols or direct references to the _bfd_link_add_symbols function pointer. 4. GDB does use struct bfd_link_info in one place — gdb/compile/compile-object-load.c — but only to call bfd_get_relocated_section_contents for relocating compiled-in expressions. It never calls bfd_link_add_symbols in that code path either. This aligns with what I was expecting given what the function does. I've then gone and confirmed all of these details by hand and I believe that this analysis is correct, GDB doesn't make use of xcoff_link_add_symbols, and so this issue does not impact GDB.