[PATCH v3] [PR corefiles/32441] Fix segfault if target_fileio_read_alloc fails

[Brandon Belew <brandon.belew@zetier.com>]

Was: Re: GDB 16.3 release - 2025-03-01 update. This is a v3 of my patch
as requested by Joel Brobecker with a link to the bugzilla PR included
in the commit message.

Joel Brobecker <brobecker@adacore.com> writes:
> Hello Brandon,
> 
>> Hi, I'm a new contributor and I don't have permissions to modify the
>> Target Milestone on the bug I reported in bugzilla, but bug 32441 [1]
>> has an attached patch that was just approved by Andrew Burgess; see
>> Message ID <87ikouz5ys.fsf@redhat.com> [2]. This fixes a segfault in
>> core file generation, much like the other corefiles/32634 fix already
>> being included in the 16.3 release. I would love to see this fix
>> included!
>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=32441
>> [2] https://sourceware.org/pipermail/gdb-patches/2025-February/215909.html
>
> Thanks for the heads up and the references.
>
> I think the request to backport looks reasonable to me, but you will
> need one of the Global Maintainers to also approve the backport.
>
> If you haven't pushed the patch to master yet, can you amend
> the commit message to include the URL to the GDB PR so that
> bugzill automatically gets notified that this was pushed, and
> logs its in the activity log?
>
> If you have already pushed to master, no problem, but can you
> at least make sure you do this for the version that gets pushed
> to the gdb-16-branch (after it gets approved for backporting)?
>
> Thank you!

Thanks for the updates, Joel. I do not have any commit rights, so my
patch hasn't been comitted anywhere. I'm not sure what that process
looks like as this is my first contribution. I've been trying to get
this merged since December and Andrew gave it a "LGTM" on Feb 28; does
someone else need to approve it before it can be merged? Is there
someone else I need to ping to request the patch be merged now that it
has been approved? Given that it hasn't been merged yet, I can update
the commit message to include the link to bugzilla, although I did
include "[PR corefiles/32441]" in the subject line of my patch which I
thought was sufficient. At any rate, here's an updated patch that
includes the URL within the commit message.


---
Check for target_fileio_read_alloc failure in linux_fill_prpsinfo
before dereferencing buffer. This fixes a segfault in the 'gcore'
command when attached to certain remote targets.

Fixes https://sourceware.org/bugzilla/show_bug.cgi?id=32441
---
 gdb/linux-tdep.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index d3ab02d03e0..735d20dc050 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -854,7 +854,7 @@ linux_info_proc (struct gdbarch *gdbarch, const char *args,
     {
       xsnprintf (filename, sizeof filename, "/proc/%ld/cmdline", pid);
       gdb_byte *buffer;
-      ssize_t len = target_fileio_read_alloc (NULL, filename, &buffer);
+      LONGEST len = target_fileio_read_alloc (nullptr, filename, &buffer);

       if (len > 0)
 	{
@@ -2180,17 +2180,17 @@ linux_fill_prpsinfo (struct elf_internal_linux_prpsinfo *p)
   /* The number of fields read by `sscanf'.  */
   int n_fields = 0;

-  gdb_assert (p != NULL);
+  gdb_assert (p != nullptr);

   /* Obtaining PID and filename.  */
   pid = inferior_ptid.pid ();
   xsnprintf (filename, sizeof (filename), "/proc/%d/cmdline", (int) pid);
   /* The full name of the program which generated the corefile.  */
-  gdb_byte *buf = NULL;
-  size_t buf_len = target_fileio_read_alloc (NULL, filename, &buf);
+  gdb_byte *buf = nullptr;
+  LONGEST buf_len = target_fileio_read_alloc (nullptr, filename, &buf);
   gdb::unique_xmalloc_ptr<char> fname ((char *)buf);

-  if (buf_len < 1 || fname.get ()[0] == '\0')
+  if (buf_len < 1 || fname.get () == nullptr || fname.get ()[0] == '\0')
     {
       /* No program name was read, so we won't be able to retrieve more
 	 information about the process.  */
--
2.47.1