[Bug gdb/26804] New: gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[Bug gdb/26804] New: gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[3480283348 at qq dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

            Bug ID: 26804
           Summary: gdbserver crash at <init_cacheinfo+22> when program
                    has canary and is 32 bit.
           Product: gdb
           Version: 9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: 3480283348 at qq dot com
  Target Milestone: ---

here is my test program.
```
#include <stdio.h>
#include <stdlib.h>

void test()
{
    int a = 1;
    int buffer[128];
    printf("a = %d\n", a);
}

int main()
{
    test();
}
```

And compile this program as 32bit on x86_64.
```
gcc test.c -o test -g -m32
```

using gdb works fine. Then use gdbserver and gdb on local machine.
```
# terminal 01
gdbserver localhost:11111 test

# terminal 02
gdb
target remote localhost:11111
continue
```

Gdbserver will crash at <init_cacheinfo+22> which deal with canary.
```
Program received signal SIGSEGV, Segmentation fault.
0xf7dd9ce6 in init_cacheinfo () from target:/usr/lib32/libc.so.6
-> 0xf7dd9ce6 <init_cacheinfo+22> mov    eax, gs:0x14
-> $gs: 0x0063 
```

> OS: GUN/Linux x86_64

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |simark at simark dot ca
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-10-29

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
I was able to reproduced.

I ran the program side by side in GDB and in GDB+GDBserver.  The execution look
identical,yet the one in GDB+GDBserver received a SIGSEGV.  I don't know why.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[3480283348 at qq dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

Allen_Hong <3480283348 at qq dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|9.2                         |10.1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[3480283348 at qq dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

--- Comment #2 from Allen_Hong <3480283348 at qq dot com> ---
Well, I find it is caused by changing of linux kernel.  Kernel which is before
linux-5.9 version does not have this bug. However, I can not find the position
causing this bug because of my poor ability...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
I can also reproduce this, on openSUSE tumbleweed, with kernel version 5.9.10,
on pretty much all gdb.server/*.exp test-cases.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[bp at alien8 dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

Borislav Petkov <bp at alien8 dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bp at alien8 dot de

--- Comment #4 from Borislav Petkov <bp at alien8 dot de> ---
Yap, looks like it is fsgsbase-related. Try booting your kernel with
"nofsgsbase" as a temp workaround. See:

https://lkml.kernel.org/r/20210111181520.GE25645@zn.tnic

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[markus.t.metzger at intel dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

Markus Metzger <markus.t.metzger at intel dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markus.t.metzger at intel dot com

--- Comment #5 from Markus Metzger <markus.t.metzger at intel dot com> ---
Gdbserver is overwriting the gs_base that ptrace provides with zero.  I have
not checked GDB.

Looks like neither GDB nor gdbserver actually support fs_base and gs_base for
32-bit inferiors when GDB is 64-bit.  And gdbserver does not seem to support
them at all, even for 64-bit inferiors.

No idea why gs_base is not preserved as it should be.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
I found the place in gdbserver where gs_base is overwritten. It's in
x86_fill_gregset:
...
  /* 32-bit inferior registers need to be zero-extended.                        
     Callers would read uninitialized memory otherwise.  */
  memset (buf, 0x00, X86_64_USER_REGS * 8);                                     
...

Commenting out the memset fixes the segmentation fault.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #6)
> I found the place in gdbserver where gs_base is overwritten. It's in
> x86_fill_gregset:
> ...
>   /* 32-bit inferior registers need to be zero-extended.                    
> 
>      Callers would read uninitialized memory otherwise.  */
>   memset (buf, 0x00, X86_64_USER_REGS * 8);                                 
> 
> ...
> 
> Commenting out the memset fixes the segmentation fault.

Hmm, but that causes regressions on Leap 15.2 (with 5.3.18 kernel).

This doesn't cause any regressions on Leap 15.2, and still fixes the problem on
Tumbleweed (with 5.10.5 kernel):
...
diff --git a/gdbserver/linux-x86-low.cc b/gdbserver/linux-x86-low.cc
index 35dfdd7e0f3..d2abf3c2712 100644
--- a/gdbserver/linux-x86-low.cc
+++ b/gdbserver/linux-x86-low.cc
@@ -414,7 +414,11 @@ x86_fill_gregset (struct regcache *regcache, void *buf)

   /* 32-bit inferior registers need to be zero-extended.
      Callers would read uninitialized memory otherwise.  */
-  memset (buf, 0x00, X86_64_USER_REGS * 8);
+  {
+    unsigned long long *ptr = (unsigned long long *)buf;
+    for (i = 0; i < X86_64_USER_REGS; ++i)
+      ptr[i] = ptr [i] & 0xffffffffULL;
+  }
 #endif

   for (i = 0; i < I386_NUM_REGS; i++)
...

Effectively, the patch fixes the code to match the comment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug server/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|gdb                         |server

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug server/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[markus.t.metzger at intel dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

--- Comment #8 from Markus Metzger <markus.t.metzger at intel dot com> ---
This zero-extends all registers in the 64-bit regmap, not just those in the
32-bit regmap that get collected later on.  We should rather preserve what's in
the buffer unless we're intentionally overwriting it.  Should we remove the
memset here and zero-extend the registers that we collect in the loop below?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug server/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[markus.t.metzger at intel dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

--- Comment #9 from Markus Metzger <markus.t.metzger at intel dot com> ---
users/mmetzger/fsgs is adding support for FSGSBASE for 64-bit GDB debugging
32-bit inferiors.  so far, for native only.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug server/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 13132
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13132&action=edit
Tentative patch

(In reply to Markus Metzger from comment #8)
> This zero-extends all registers in the 64-bit regmap, not just those in the
> 32-bit regmap that get collected later on.  We should rather preserve what's
> in the buffer unless we're intentionally overwriting it.  Should we remove
> the memset here and zero-extend the registers that we collect in the loop
> below?

Currently testing this approach.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug server/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch submitted:
https://sourceware.org/pipermail/gdb-patches/2021-January/175233.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug server/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed by:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=037e8112b9794a633248e5aa5943f3be273e0a20

[gdb/server] Don't overwrite fs/gs_base with -m32

Consider a minimal test-case test.c:
...
int main (void) { return 0; }
...
compiled with -m32:
...
$ gcc test.c -m32
...

When running the exec using gdbserver on openSUSE Factory (currently running a
linux kernel version 5.10.5):
...
$ gdbserver localhost:12345 a.out
...
to which we connect in a gdb session, we run into a segfault in the inferior:
...
$ gdb -batch -q -ex "target remote localhost:12345" -ex continue
Program received signal SIGSEGV, Segmentation fault.
0xf7dd8bd2 in init_cacheinfo () at ../sysdeps/x86/cacheinfo.c:761
...

The segfault is caused by gdbserver overwriting $gs_base with 0 using
PTRACE_SETREGS.  After it is overwritten, the next use of $gs in the inferior
will trigger the segfault.

Before linux kernel version 5.9, the value used by PTRACE_SETREGS for $gs_base
was ignored, but starting version 5.9, the linux kernel has support for
intel architecture extension FSGSBASE, which allows users to modify $gs_base,
and consequently PTRACE_SETREGS can no longer ignore the $gs_base value.

The overwrite of $gs_base with 0 is done by a memset in x86_fill_gregset,
which was added in commit 9e0aa64f551 "Fix gdbserver qGetTLSAddr for
x86_64 -m32".  The memset intends to zero-extend 32-bit registers that are
tracked in the regcache to 64-bit when writing them into the PTRACE_SETREGS
data argument.  But in addition, it overwrites other registers that are
not tracked in the regcache, such as $gs_base.

Fix the segfault by redoing the fix from commit 9e0aa64f551 in minimal form.

Tested on x86_64-linux:
- openSUSE Leap 15.2 (using kernel version 5.3.18):
  - native
  - gdbserver -m32
  - -m32
- openSUSE Factory (using kernel version 5.10.5):
  - native
  - m32

gdbserver/ChangeLog:

2021-01-20  Tom de Vries  <tdevries@suse.de>

* linux-x86-low.cc (collect_register_i386): New function.
(x86_fill_gregset):  Remove memset.  Use collect_register_i386.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug server/26804] gdbserver crash at <init_cacheinfo+22> when program has canary and is 32 bit.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26804

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |11.1

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
Marking resolved-fixed with milestone 11.1.

We could consider this though for 10.2

-- 
You are receiving this mail because:
You are on the CC list for the bug.