[Bug nptl/17398] New: setresuid makes an invalid syscall on i686-linux when compiled with -pthread

[Bug nptl/17398] New: setresuid makes an invalid syscall on i686-linux when compiled with -pthread

[mhw at netris dot org]

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

            Bug ID: 17398
           Summary: setresuid makes an invalid syscall on i686-linux when
                    compiled with -pthread
           Product: glibc
           Version: 2.20
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: mhw at netris dot org
                CC: drepper.fsp at gmail dot com

Created attachment 7790
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7790&action=edit
setresuid test program

The attached test program generates an apparently bogus syscall when
compiled with "gcc -o setresuid-test setresuid-test.c -pthread" on
i686-linux using glibc-2.20.  The output is:

  getresuid => ruid 1000, euid 1000, suid 1000, result 0
  setresuid (1000, 1000, 1000) => result -1, errno 38

and here are the last few lines of strace output:

  getresuid32([1000], [1000], [1000])     = 0
  fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb75c4000
  write(1, "getresuid => ruid 1000, euid 100"..., 55) = 55
  syscall_3076282112(0x3e8, 0x3e8, 0x3e8, 0xb75c5700, 0xb777f000, 0xb77811a4) =
-1 (errno 38)
  write(1, "setresuid (1000, 1000, 1000) => "..., 52) = 52
  exit_group(0)                           = ?
  +++ exited with 0 +++

Notice the apparently bogus "syscall_3076282112".

The same test results in a non-bogus setresuid syscall with return
value 0 in at least the following cases:

* when using glibc-2.20 on i686-linux without -pthread
* when using glibc-2.20 on x86_64-linux with -pthread
* when using glibc-2.19 on i686-linux with -pthread

Here's the output on i686-linux with glibc-2.20 without -pthread:

  getresuid => ruid 1000, euid 1000, suid 1000, result 0
  setresuid (1000, 1000, 1000) => result 0, errno 0

and here are the last few lines of the associated strace output:

  getresuid32([1000], [1000], [1000])     = 0
  fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7618000
  write(1, "getresuid => ruid 1000, euid 100"..., 55) = 55
  setresuid32(1000, 1000, 1000)           = 0
  write(1, "setresuid (1000, 1000, 1000) => "..., 50) = 50
  exit_group(0)                           = ?
  +++ exited with 0 +++

The same problem happens with setresgid.

These tests were done on GNU Guix <http://gnu.org/s/guix> using GCC
4.8.3 and Binutils 2.24 on i686-pc-linux-gnu, running on linux-libre
3.16.1.

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

[Bug nptl/17398] setresuid makes an invalid syscall on i686-linux when compiled with -pthread

[mhw at netris dot org]

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

Mark H Weaver <mhw at netris dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mhw at netris dot org

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

[Bug nptl/17398] setresuid makes an invalid syscall on i686-linux when compiled with -pthread

[schwab@linux-m68k.org]

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

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
Your libc is being miscompiled.

*** This bug has been marked as a duplicate of bug 17380 ***

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