[Bug 901252] Re: atoi segfaults if the auxiliary vector was empty

[Edmund Grimley Evans]

> I'm not sure how intentionally corrupting the stack with a debugger to
> cause a segfault constitutes a glibc bug...

Setting the auxiliary vector to empty is not really "corrupting" it. You
just need to ask yourself whether you consider it acceptable for the C
library to segfault when presented with an empty auxiliary vector as
input. Perhaps you do, in which case this behaviour isn't a bug. On the
other hand, if you think the C library should be able to cope more
elegantly with an empty auxiliary vector then my report provides
evidence that something is not working as it should. Your choice.

I don't claim that my technique for demonstrating the problem
"constitutes" a bug. By all means go ahead and demonstrate the problem
by patching the kernel instead, if you prefer. Or perhaps you could
demonstrate it with valgrind.

Or perhaps you're not interested in glibc bugs that do not affect the
normal use of glibc on Linux. I don't really know who you are and what
your area of interest is.

-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium.  Thank you.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/901252

Title:
  atoi segfaults if the auxiliary vector was empty

Status in “eglibc” package in Ubuntu:
  Invalid

Bug description:
  The auxiliary vector is put onto a process's stack by the kernel and
  it normally isn't empty. However, the C library is probably supposed
  to cope with the auxiliary vector being empty (you might be running
  the program under a different or a modified operating system).
  Therefore, it is probably a bug that atoi segfaults when the auxiliary
  vector was empty.

  I tested this with libc6-dev_2.13-0ubuntu13_armel.deb on a Panda
  Board. I haven't seen this bug on x86.

  To demonstrate the bug you have to use the debugger to hide the
  auxiliary vector. See the transcript below in which I:

  - Build a simple statically linked binary that calls atoi().
  - Find the entry point.
  - Run the program under GDB and stop it at the entry point.
  - Find the auxiliary vector on the stack and hide it by overwriting the first tag with 0.
  - Let the program continue to run: it segfaults in strtol.

  $ cat <<END > t.c
  #include <stdio.h>
  #include <stdlib.h>
  int main()
  {
    printf("%d\n", atoi("123"));
    return 0;
  }
  END
  $ gcc -Wall -O2 t.c -static
  $ readelf -l a.out | grep Entry
  Entry point 0x8171
  $ gdb a.out
  ...
  (gdb) b *0x8170
  Breakpoint 1 at 0x8170
  (gdb) r
  Starting program: /export/egrimley/a.out 

  Breakpoint 1, 0x00008170 in _start ()
  (gdb) info reg
  ...
  sp             0xbefff7d0...
  ...
  (gdb) x/64x 0xbefff7d0
  0xbefff7d0:	0x00000001	0xbefff8dc	0x00000000	0xbefff8f3
  0xbefff7e0:	0xbefff903	0xbefff90e	0xbefff95e	0xbefff97e
  0xbefff7f0:	0xbefff991	0xbefff99f	0xbefffe8f	0xbefffe9a
  0xbefff800:	0xbefffee7	0xbefffeff	0xbeffff0e	0xbeffff1b
  0xbefff810:	0xbeffff30	0xbeffff3d	0xbeffff46	0xbeffff5a
  0xbefff820:	0xbeffff62	0xbeffff73	0xbeffffa3	0xbeffffc3
  0xbefff830:	0x00000000	0x00000010	0x0000b8d7	0x00000006
  0xbefff840:	0x00001000	0x00000011	0x00000064	0x00000003
  ...
  (gdb) p *(int *)0xbefff834 = 0
  $1 = 0
  (gdb) c
  Continuing.

  Program received signal SIGSEGV, Segmentation fault.
  0x00008c1c in ____strtol_l_internal ()

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/901252/+subscriptions